Opened 10 years ago
Closed 4 years ago
#11883 closed enhancement (not reproducible)
Debugger fails to parse debug output generated by rustc/llvm
Reported by: | nielx | Owned by: | anevilyak |
---|---|---|---|
Priority: | low | Milestone: | |
Component: | Applications/Debugger | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
I have ported the rust compiler to Haiku. I have generated a small application. The issue is that even though I compile with debug output, Debugger cannot seem to find the application's main file.
I have explicitly set LLVM to generate Dwarf2 debug output.
Attachments (2)
Change History (8)
by , 10 years ago
Attachment: | readdir-test added |
---|
by , 10 years ago
Attachment: | readdir-test.rs added |
---|
comment:1 by , 10 years ago
Component: | - General → Applications/Debugger |
---|
comment:2 by , 10 years ago
Priority: | normal → low |
---|---|
Type: | bug → enhancement |
There are several issues at play here. First of all, up until now, the main emphasis on Debugger's development has been handling C/C++, as those are the primary languages used by the system APIs. There are large chunks of the DWARF spec that exist solely to serve various language-specific quirks, and as such quite a few of those aren't currently implemented due to lack of need until now.
Second, and more relevant to this specific issue, the ability to generically determine the correct starting symbol (via DW_AT_main_subprogram) wasn't added until DWARF version 4 ; for versions prior to that, and/or in the absence of debugging information, determining the start location has to be handled manually on a per-language basis. The output attached to this binary doesn't contain such a marker, so it falls into the latter category. Since I already have a large enough todo list of other things to add, and a relatively limited time budget at the moment, implementing support for relatively obscure languages isn't something I'm likely to have the time/motivation to do any time soon. As such, I'm afraid I'm going to have to simply say "patches welcome" here.
follow-up: 4 comment:3 by , 10 years ago
I'm very happy to look into this and supply patches, though I might have some questions along the way. I will start with looking at the versioning, I will also start generating DWARF4 output, since that's obviously where the future is.
Question: not recognizing the source file, where would I start?
comment:4 by , 10 years ago
Replying to nielx:
Question: not recognizing the source file, where would I start?
That depends on which of the above two problems it's hitting ; if it's failing to parse the actual DWARF output due to hitting a construct it doesn't know how to handle, then it will wind up falling back to basic disassembly. If that's the case, then tracking down what it's not able to handle will entail enabling some tracing via http://cgit.haiku-os.org/haiku/tree/build/config_headers/apps_debugger_config.h ; note that you can create a copy of this file in the subdir build/user_config_headers and modify it there for your personal uses. I would start by enabilng APPS_DEBUGGER_TRACE_DWARF_DIE
and possibly also APPS_DEBUGGER_TRACE_IMAGES
.
If you then build Debugger with those flags enabled, and try running it against your rust binary from the CLI, you should get a fair amount of output from the DWARF parsing process, which should also indicate an error if it hits one. Unfortunately, there isn't currently much in the way of documentation for Debugger's internals, so we'll have to take this as we go with regards to finding problems. The lower level parsing code for handling DWARF is primarily in the various files comprising the dwarf/ subdir in any case. I'd suggest taking this to email from here on out so we don't wind up cluttering the ticket in any case though.
comment:5 by , 4 years ago
Milestone: | R1 → Unscheduled |
---|
comment:6 by , 4 years ago
Milestone: | Unscheduled |
---|---|
Resolution: | → not reproducible |
Status: | new → closed |
With recent Rust builds, Debugger seems to be able to locate the symbols. I am guessing somewhere along the way the LLVM output became more to our liking.
Executable