On Fri, 28 Jan 2022 09:38:14 GMT, Christian Hagedorn <chaged...@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
