-
Notifications
You must be signed in to change notification settings - Fork 102
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
DWARF support #166
Comments
Does this cover eh_frame too? |
Added |
From m4b/faerie#51 (comment) by @philipc:
I don't see the (please note that I had to rebase both branches to get it working with the latest nightly)
Posting here, because I think this is a more appropriate place to continue this conversation. |
I'll look into it later today, but maybe you need to change the DWARF version to 4. I've been using gimli's dwarfdump, I'll try llvm-dwarfdump later. |
Thanks. Using version 4 fixes it. |
I rebased @philipc's It is currently blocked on |
|
Looks like gdb ignores
This duplication of arguments as variables is unnecessary and should be avoided (see rust-lang/rust#45380). |
Thanks. I renamed the |
Note to self:
|
@philipc could you advise me some other sources about DWARF information than the spec? |
Most of my information comes from:
If you have a specific question I can try to answer. |
Thanks, I have no questions at the moment though. |
#291 has been merged! 🎉 |
Thanks for your effort on this! Is this at a stage to try out debugging? |
Cranelift can optimize SSA variables (those storing primitive values and not having their address taken) away (though not sure if it also does this when opt_level is set to none, like cg_clif currently does) when there is no user. When compiling in release mode, some stack slot accesses turn into SSA variables. I haven't yet implemented correct debuginfo generation for this. In all other cases variables are not optimized away. Currently debuginfo generation for locals is disabled, as there are still a lot of unhandled types and storage locations. Lineinfo is supported, though with some small issues. For example when returning from a function, the current line temporarily jumps to the start of the function (https://github.com/bytecodealliance/cranelift/issues/1172). Also single stepping goes into macros. It is usable though. |
a49416d will remove stub local debuginfo implementation. It isn't actually wired up and temporarily removing it will make changes to the debuginfo generation code much simpler. I will reintroduce this code at a later point. |
In fee1204...4f0cde1 I fixed debug info generation for arrays, implemented it for tuples and define return types for functions. |
Would this issue allow gdb to load symbols? A core dump from cranelift is unfortunately pretty useless right now. I also noticed that local variables don't show up. |
Symbols and source locations should be fully working already. As for local variables, that indeed still needs to be implemented. |
Sort of, but not really. This is cranelift:
Here's LLVM:
File locations and generics are broken. Also gdb complains with cranelift:
|
@SUPERCILEX I tested current nightly with ringboard-egui, and gdb can display a backtrace for a core dump for me. Can you provide more detail on your environment? e.g. which linker are you using? And maybe open a new issue for this. |
Hmm, ok I just updated to the latest rust nightly and now generics are filled in properly (still no arguments but I assume that's the same thing as locals). Sorry for the noise. |
Edit: add unwinding information
Edit2: state which things are for the long term
Edit3: gimli-rs/gimli#340 has been merged
Edit4: m4b/faerie#51 has been merged and CraneStation/cranelift#426 is not necessary anymore I believe.
The text was updated successfully, but these errors were encountered: