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

We currently require clang 3.5 (when building on linux I presume; Xcode has 
their very own peculiar way of versioning clang). Maybe this is too old? Should 
we instead raise the bar to require clang 5.0, so we can skip the test?

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

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

Reply via email to