-
Notifications
You must be signed in to change notification settings - Fork 13.3k
emit DW_AT_main_subprogram #32620
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.
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
Comments
I can't find any way to make LLVM do this |
FWIW I have a patch to LLVM to add the necessary bits. Now I'm investigating how to get the information from the driver to |
See rust/src/librustc_trans/base.rs Line 1144 in 43006fc
This is how you can get the DefId of the main function.
|
Ok, I have this working. I sent a patch to llvm-commits, but it needs moderator approval to go through, and then of course patch review. I also have a rustc patch that works, but I haven't written a test case yet. One possible issue is that the patch that applies to Rust's llvm is different from the patch I sent upstream. My current plan is to wait until something goes in upstream, then backport it and submit a PR to the Rust fork. |
Sounds like a good course of action |
I'd like the Rust compiler to emit DW_AT_main_subprogram in its DWARF output, so that debuggers can find the user-provided main entry point. See rust-lang/rust#32620 This patch adds support for DW_AT_main_subprogram to LLVM to support this effort. A variant of this patch was accepted by upstream LLVM; there, DebugInfoFlags.def already has a flag with value 1<<20, which is why this patch uses 1<<21 -- this will avoid the need to change the Rust compiler when a new LLVM is imported.
I'd like the Rust compiler to emit DW_AT_main_subprogram in its DWARF output, so that debuggers can find the user-provided main entry point. See rust-lang/rust#32620 This patch adds support for DW_AT_main_subprogram to LLVM to support this effort. A variant of this patch was accepted by upstream LLVM; there, DebugInfoFlags.def already has a flag with value 1<<20, which is why this patch uses 1<<21 -- this will avoid the need to change the Rust compiler when a new LLVM is imported.
I'd like the Rust compiler to emit DW_AT_main_subprogram in its DWARF output, so that debuggers can find the user-provided main entry point. See rust-lang/rust#32620 This patch adds support for DW_AT_main_subprogram to LLVM to support this effort. A variant of this patch was accepted by upstream LLVM; there, DebugInfoFlags.def already has a flag with value 1<<20, which is why this patch uses 1<<21 -- this will avoid the need to change the Rust compiler when a new LLVM is imported.
You can see my patch here: https://github.com/tromey/rust/tree/main-subprogram I think I can't really submit it until the rust-llvm patch is reviewed, because the final rust patch will have to include a change to the submodule revision. |
Also, FYI, the gdb patch is still pending; I will ping it either tomorrow or Friday. |
What happens if you're using an external (unpatched) LLVM? Will it ignore the unrecognized flag? |
I think it depends on the precise version of LLVM. The version that Rust is using doesn't check flags less than 1<<27 (IIRC), but LLVM trunk checks that the flag is in range -- which is one reason the upstream LLVM patch is a bit different. I didn't look to see when this change was made in LLVM, but I could if you like. |
Currently, Rust supports external LLVM 3.7+, so if unpatched LLVM won't handle this gracefully, it will have to be only conditionally added. Rust's own is (roughly) 3.9, so if that's not checking flags then I guess it's ok -- the change must have happened only during 4.0 development, which now has your addition before its release anyway. |
FWIW the gdb patch went in today. |
This changes rustc to emit DW_AT_main_subprogram on the "main" program. This lets gdb suitably stop at the user's main in response to "start" (rather than the library's main, which is what happens currently). Fixes rust-lang#32620 r? michaelwoerister
Emit DW_AT_main_subprogram This changes rustc to emit DW_AT_main_subprogram on the "main" program. This lets gdb suitably stop at the user's main in response to "start" (rather than the library's main, which is what happens currently). Fixes #32620 r? michaelwoerister
When making an executable, rustc should emit
DW_AT_main_subprogram
on the CU and the subprogram DIE for the main function that is going to be executed bymain
.This marker would allow gdb's
start
command to find the correct spot in user code to set an initial breakpoint. (This doesn't work yet, see https://sourceware.org/bugzilla/show_bug.cgi?id=16264 - but could be made to work.)The text was updated successfully, but these errors were encountered: