Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#9799 closed enhancement (fixed)

Implement support for call site extensions

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

Description

gcc 4.7 implements some new draft extensions to DWARF with respect to call site information, as documented at http://www.dwarfstd.org/ShowIssue.php?issue=100909.2&type=open

These need to be eventually properly handled, but at least the minimum needs to be implemented to parse them at first so we can properly handle binaries with those extensions.

Change History (12)

comment:1 Changed 6 years ago by scanty

Hi. I tried compiling with -gdwarf-2 and -gstrict-dwarf and there is still no source path in the debugger, making it impossible to debug. mmadia suggested that as hrev45516 works and hrev45704 doesn't, I'm guessing ASLR/DEP. Could this be the underlying problem?

comment:2 Changed 6 years ago by anevilyak

No, ASLR's unrelated to that part, it's strictly a matter of the debugger handling the aforementioned extensions, which were introduced by the recent upgrade to gcc 4.7. Another possibility would be to use gcc2 if your code allows it, since it by definition can't emit those.

Last edited 6 years ago by anevilyak (previous) (diff)

comment:3 Changed 6 years ago by anevilyak

Another factor that can make a difference is optimization level: when using -g, are you using -O0 as well, or are you leaving your normal optimization level? Leaving optimizations turned on can make debugging a bit more complicated due to the potential changes the compiler can make, such as removing lines of code/functions entirely, so it's generally not a good idea unless you literally can't reproduce the problem without it.

The call site extensions are generally intended to help the debugger cope with precisely that kind of optimization case, so using -g -O0 might be another way to prevent them from being generated at all if gcc2 isn't an option.

comment:4 Changed 6 years ago by scanty

The code in question that is crashing is in assembly and written in NASM. I don't think the compiler would touch it, but I can try -O0. gcc2 is not an option, as there are a fair number of templates, and we're using the boost library which I could never get working properly on BeOS 5.

comment:5 Changed 6 years ago by scanty

As for ASLR/DEP, I meant the crash itself in general, and not necessarily the debugging problem.

comment:6 in reply to:  4 Changed 6 years ago by anevilyak

Replying to scanty:

The code in question that is crashing is in assembly and written in NASM. I don't think the compiler would touch it, but I can try -O0. gcc2 is not an option, as there are a fair number of templates, and we're using the boost library which I could never get working properly on BeOS 5.

Yes, for the ASM part it won't matter, but that's more or less irrelevant, since as far as the debug information is concerned, the entire executable matters since all of the relevant debugging information is stored in a single giant binary structure. The fact that those extensions are present is causing us to fail to parse said structure, and consequently falling back to basic information only without debug info assistance.

comment:7 Changed 6 years ago by scanty

I tried compiling with -O0 as you suggested and there is still no source path. If there's anything else you'd like me to try, just let me know. I'm just as anxious (well maybe a little less) to get the debugger debugging as you are.

comment:8 Changed 6 years ago by anevilyak

Resolution: fixed
Status: newclosed

Basic handling implemented in hrev45721. I can't fully verify all behavior in the case of Pretendo since I lack the actual corresponding source files, but we at least fully parse the info now, and as such try to find said files.

comment:9 Changed 6 years ago by korli

As a side note, if needed, we could probably set "-gstrict-dwarf" as the GCC default for the Haiku target.

comment:10 Changed 6 years ago by scanty

What about -gdwarf-2? Just curious.

comment:11 Changed 6 years ago by korli

I believe it's already the default (dwarf4 becomes the default beginning with 4.8).

comment:12 in reply to:  9 Changed 6 years ago by anevilyak

Replying to korli:

As a side note, if needed, we could probably set "-gstrict-dwarf" as the GCC default for the Haiku target.

We could, but at least for this ticket it appeared to make no difference, so I'm not sure how "strict" gcc actually is about following that directive.

Note: See TracTickets for help on using tickets.