Implement support for call site extensions

[anevilyak]

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.

[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?

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

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

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

[scanty]

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

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

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

[anevilyak]

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.

[korli]

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

[scanty]

What about -gdwarf-2? Just curious.

[korli]

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

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