Opened 4 years ago

Last modified 4 years ago

#11883 new enhancement

Debugger fails to parse debug output generated by rustc/llvm

Reported by: nielx Owned by: anevilyak
Priority: low Milestone: R1
Component: Applications/Debugger Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


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)

readdir-test (3.0 MB) - added by nielx 4 years ago.
Executable (497 bytes) - added by nielx 4 years ago.

Change History (6)

Changed 4 years ago by nielx

Attachment: readdir-test added


Changed 4 years ago by nielx

Attachment: added

comment:1 Changed 4 years ago by diver

Component: - GeneralApplications/Debugger

comment:2 Changed 4 years ago by anevilyak

Priority: normallow
Type: bugenhancement

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.

comment:3 Changed 4 years ago by nielx

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 in reply to:  3 Changed 4 years ago by anevilyak

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 ; 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.

Note: See TracTickets for help on using tickets.