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

[Zhengyu Gu]

On Fri, 28 Jan 2022 09:38:14 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> > > That's interesting. Is this implementation still around somewhere? I'm glad that some of the mentioned things are not a problem anymore.
> > 
> > 
> > Not I know. IIRC, it was based on DWARF 2.
> 
> Okay, thanks.
> 
> > > > * 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.
> > 
> > 
> > I think maintenance and test could be major pain points. Based on build.html, we can use gcc version anywhere between 5.0 and 10.2, it could be a challenge to ensure all supported version work correctly.
> 
> I agree, that wide range is a problem and older GCC versions emitting older DWARF version are not covered with this patch. If I parse a DWARF section header with an unsupported version I will just bail out and it falls back to the stack trace we are seeing today without source information. That's probably fine for the scope of this patch. We could still come back and add support for other missing versions.

I see, it makes sense. Thanks!

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

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