On Tue, 11 Oct 2022 08:18:08 GMT, Christian Hagedorn <chaged...@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 > > Christian Hagedorn has updated the pull request with a new target base due to > a merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains six additional > commits since the last revision: > > - Always read full filename and strip prefix path and only then cut filename > to fit output buffer > - Merge branch 'master' into JDK-8293422 > - Merge branch 'master' into JDK-8293422 > - Review comments from Thomas > - Change old bailout fix to only apply to Clang versions older than 5.0 and > add new fix with -gdwarf-aranges + -gdwarf-4 for Clang 5.0+ > - 8293422: DWARF emitted by Clang cannot be parsed If is is a big change or not depends on how it affects builds on macos. I assume that clang functionality that was published in 2017 is already incorporated in the minimum supported version of Xcode on mac. (This needs to be verified, though) For clang on linux; Oracle do not regularly build linux with clang, nor do our GHA build scripts. I don't know if anyone regularly tests this. My guess is that the 3.5 limit was put in place when the clang for linux support was added, and it has not been modified since. But you are probably right that it should be a separate PR, if not for anything else so to get proper attention to it. Do you want me to publish such a PR first, or do you want to continue with the current conditionals, and clean them up afterwards if/when we go to clang 5.0+? ------------- PR: https://git.openjdk.org/jdk/pull/10287
