Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ICE: inlinable function call in a function with debug info must have a !dbg location #35566

Closed
petrochenkov opened this issue Aug 10, 2016 · 8 comments
Closed

ICE: inlinable function call in a function with debug info must have a !dbg location #35566

petrochenkov opened this issue Aug 10, 2016 · 8 comments
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) O-windows-gnu Toolchain: GNU, Operating system: Windows

Comments

@petrochenkov
Copy link
Contributor

Happens at stage 1 during rustc bootstrap with enabled debug info and MIR on Windows/GNU.

./configure --enable-debug --enable-optimize
make rustc-stage1 VERBOSE=1

Result:

CFG_LLVM_LINKAGE_FILE=/home/we/rust/x86_64-pc-windows-gnu/rt/llvmdeps.rs PATH=/home/we/rust/x86_64-pc-windows-gnu/stage1/bin:/home/we/rust/x86_64-pc-windows-gnu/llvm/lib:$PATH   x86_64-pc-windows-gnu/stage1/bin/rustc.exe --cfg stage1  -O --cfg rtopt -C debug-assertions=on -g -C rpath -C prefer-dynamic --target=x86_64-pc-windows-gnu   -L "x86_64-pc-windows-gnu/rt" -L native="C:/msys64/home/we/rust/x86_64-pc-windows-gnu/llvm/lib"     --out-dir x86_64-pc-windows-gnu/stage1/lib/rustlib/x86_64-pc-windows-gnu/lib -C extra-filename=-f53fb285 -C metadata=f53fb285 src/libpanic_unwind/lib.rs
inlinable function call in a function with debug info must have a !dbg location
  call void @rust_eh_unwind_resume(i8* %7)
LLVM ERROR: Broken function found, compilation aborted!
make: *** [/home/we/rust/mk/target.mk:216: x86_64-pc-windows-gnu/stage1/lib/rustlib/x86_64-pc-windows-gnu/lib/stamp.panic_unwind] Error 1

This looks very similar to #35141
cc @eddyb @nagisa
@petrochenkov petrochenkov mentioned this issue Aug 18, 2016
Closed
@petrochenkov
Copy link
Contributor Author

I investigated this a bit, but without much success.
This is a Windows specific problem (custom_unwind_resume == true) happening when the compiled crate contains definition of lang item eh_unwind_resume (lang_items.eh_unwind_resume().is_some()), basically only libpanic_unwind.
cc @vadimcn @alexcrichton maybe you have ideas how to fix this

@eddyb
Copy link
Member

eddyb commented Aug 22, 2016

@petrochenkov The problem is this line, called from MIR trans. The fix is to move this to the call and use the Builder API instead of bcx.with_block, to get the correct debuginfo applied.

Sorry for not looking into this sooner, #35764 was a priority - we can to start getting rid of all with_block calls after it lands, and even move the smaller remaining pieces of old trans to Builder, too.

This was referenced Oct 19, 2016
Closed
Closed
@mattico mattico mentioned this issue Oct 23, 2016
Merged
@sanxiyn sanxiyn added A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) O-windows-gnu Toolchain: GNU, Operating system: Windows labels Oct 26, 2016
@est31
Copy link
Member

est31 commented Dec 9, 2016

Sadly, still not fixed yet. Ran into this when wanting to debug strange behaviour on Windows, where printf based debugging actually changed behaviour.

@est31
Copy link
Member

est31 commented Dec 9, 2016

@petrochenkov 's workaround of tagging with #[no_debug] worked for me as well.

@eddyb
Copy link
Member

eddyb commented Dec 10, 2016

It fell through the cracks again, I ended up working solely on higher-up parts of the compiler.
cc @Mark-Simulacrum Want to take on a small trans rewrite?

@Mark-Simulacrum Mark-Simulacrum mentioned this issue Dec 11, 2016
Merged
bors added a commit that referenced this issue Dec 21, 2016
@bors
Auto merge of #38302 - Mark-Simulacrum:trans-cleanup, r=eddyb
1b38776 
Cleanup old trans

This is a cleanup of old trans, with the following main points:
 - Remove the `build.rs` API (prefer using `Builder` directly, which is now passed where needed through `BlockAndBuilder`).
 - Remove `Block` (inlining it into `BlockAndBuilder`)
 - Remove `Callee::call`, primarily through inlining and simplification of code.
 - Thinned `FunctionContext`:
   - `mir`, `debug_scopes`, `scopes`, and `fn_ty` are moved to `MirContext`.
   - `param_env` is moved to `SharedCrateContext` and renamed to `empty_param_env`.
   - `llretslotptr` is removed, replaced with more careful management of the return values in calls.
   - `landingpad_alloca` is inlined into cleanup.
   - `param_substs` are moved to `MirContext`.
   - `span` is removed, it was never set to anything but `None`.
   - `block_arena` and `lpad_arena` are removed, since neither was necessary (landing pads and block are quite small, and neither needs arena allocation).
 - Fixed `drop_in_place` not running other destructors in the same function.

Fixes #35566 (thanks to @est31 for confirming).
@segevfiner
Copy link
Contributor

I just tried building master and encountered this issue. 😕

@eddyb
Copy link
Member

eddyb commented Dec 24, 2016

@segevfiner It's because the beta doesn't have the fix. Try building stage1 libstd without debuginfo then use --keep-stage 0 always with x.py so the beta compiler is not used, and only then enable debuginfo.

@cengiz-io
Copy link
Contributor

I just hit on this with my tree on 0896826 while building stage1 libstd with debuginfo on MSYS2 Windows.

I guess I should use windows only for gaming.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) O-windows-gnu Toolchain: GNU, Operating system: Windows
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@sanxiyn @eddyb @cengiz-io @petrochenkov @est31 @segevfiner