RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v2]

[Christian Hagedorn]

On Tue, 25 Jan 2022 15:06:41 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> Build changes look good.

Thanks Erik!


> Personally, I am in favor of this project. Actually, I were experimenting it with libdwarf.
> 
> I would like to add some historical background on this topic, just for consideration.

Thanks Zhengyu for sharing some background!

> We had a dwarf parser over a decade ago, a little after elf parser, but never made to mainline. There were several reasons at the time. Good news, some are no longer applied today :-)

That's interesting. Is this implementation still around somewhere? I'm glad that some of the mentioned things are not a problem anymore.

> * Different compiler (and different version of the same compiler) can generate DWARF with different version, may not be compatible with each other, as DWARF allows custom fields.
> * Maintenance cost to catch up DWARF spec/compiler changes.

That's indeed a problem of facing different DWARF versions. For this parser, I tried to support the current default of GCC 10.x which is DWARF 4. This standard was introduced in 2010 and is probably used by most compilers nowadays at least (if not already DWARF 5 which was introduced in 2017). However, even with GCC 10.x, it emitted DWARF 3 for one of the sections (I'm not sure why) which I also needed to support - thus you can never be sure. 

DWARF 5 is still experimental for GCC 10.x and had some issues when I tried that out back there - so I stayed away from implementing parsing steps for it. But now with GCC 11.x, DWARF 5 seems to have become the default. I might have to try out what's being emitted for HotSpot. But I think for now, it is better to only focus on DWARF 4 instead of trying to support various versions in one patch - we could still come back to that later if it becomes widely used. Even if DWARF 5 is emitted, GCC could be configured, for example, to emit DWARF 4 only which is probably an acceptable workaround for testing environments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7126