On Thu, 27 Jan 2022 13:43:00 GMT, Zhengyu Gu <z...@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. ------------- PR: https://git.openjdk.java.net/jdk/pull/7126