On Thu, 27 Jan 2022 08:38:02 GMT, Christian Hagedorn <chaged...@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. > Not I know. IIRC, it was based on DWARF 2. > > * 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/7126
