RFR: 8293422: DWARF emitted by Clang cannot be parsed

[Christian Hagedorn]

On Thu, 15 Sep 2022 11:59:08 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> The DWARF debugging symbols emitted by Clang is different from what GCC is emitting. While GCC produces a complete `.debug_aranges` section (which is required in the DWARF parser), Clang does not. As a result, the DWARF parser cannot find the necessary information to proceed and create the line number information:
> 
> The `.debug_aranges` section contains address range to compilation unit offset mappings. The parsing algorithm can just walk through all these entries to find the correct address range that contains the library offset of the current pc. This gives us the compilation unit offset into the `.debug_info` section from where we can proceed to parse the line number information.
> 
> Without a complete `.debug_aranges` section, we fail with an assertion that we could not find the correct entry. Since [JDK-8293402](https://bugs.openjdk.org/browse/JDK-8293402), we will still get the complete stack trace at least. Nevertheless, we should still fix this assertion failure of course. But that would require a different parsing approach. We need to parse the entire `.debug_info` section instead to get to the correct compilation unit. This, however, would require a lot more work. 
> 
> I therefore suggest to disable DWARF parsing for Clang for now and file an RFE to support Clang in the future with a different parsing approach. I'm using the `__clang__` `ifdef` to bail out in `get_source_info()` and disable the `gtests`. I've noticed that we are currently running the `gtests` with `NOT PRODUCT` which I think is not necessary - the gtests should also work fine with product builds. I've corrected this as well but that could also be done separately.
> 
> Thanks,
> Christian

Thanks Thomas for that link. I was not aware of this `-gdwarf-aranges` flag. I've tried it out and it indeed seems to work. But I was not able to build with `-flto=thin` as it resulted in build failures. So, I'm not sure what would happen and if it's even possible to build with it in general. Nevertheless, I suggest to go with that `-gdwarf-aranges` flag solution for now and remove the previously suggested bailout fix for Clang.

However, `-gdwarf-aranges` (and `-gdwarf-4` which I think we should also add to avoid getting the unsupported DWARF 5 format) was only added in Clang 5.0. But we must support down to 3.5 according to:
https://github.com/openjdk/jdk/blob/cb72f80925965c73e32c44ce3196866272306d7f/doc/building.md?plain=1#L353-L354

I therefore changed the previous complete bailout fix to a bailout fix for Clang versions older than 5.0.

I've noticed that Clang is emitting a full relative path for the filename in the form of `src/hotspot/share/compiler/compilerThread.cpp:58` with debug builds (it only emits the filename with release builds). I therefore added an additional method `strip_path_prefix()` to get rid of the path prefix.

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

PR: https://git.openjdk.org/jdk/pull/10287