RFR: 8293422: DWARF emitted by Clang cannot be parsed [v2]

[Thomas Schatzl]

On Wed, 21 Sep 2022 07:08:46 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
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   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+

Minor suggestions

src/hotspot/share/utilities/elfFile.cpp line 1632:

> 1630: // example, for Clang debug builds which emit a relative path while GCC only emits the filename.
> 1631: void DwarfFile::LineNumberProgram::strip_path_prefix(char* filename, const size_t filename_len) {
> 1632:   char* last_slash = strrchr(filename, '/');

Maybe use `os::file_separator()` instead of `/` here.

src/hotspot/share/utilities/elfFile.cpp line 1639:

> 1637:     assert(bytes_written > 0, "could not strip path prefix");
> 1638:     // Add null terminator.
> 1639:     jio_snprintf(filename + bytes_written, 1, "%s", '\0');

I think the correct format string is `%c` here. I also looked into other code that appends the `\0`, that one just pokes it in via direct assignment, but `snprintf` does not seem wrong.

test/hotspot/gtest/runtime/test_os_linux.cpp line 462:

> 460:   // This gives us either "jni.cp" or "src/ho". In the latter case, we strip the path prefix to get to the actual
> 461:   // filename which, however, is useless in this case - we get "ho".
> 462:   ASSERT_TRUE(strcmp(buf, "jni.cp") == 0 || strcmp(buf, "ho") == 0);

I did not try it out, but since we already stripped the prefix before printing the file name, why can we get "ho" here?

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

Changes requested by tschatzl (Reviewer).

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