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

[Christian Hagedorn]

On Wed, 16 Nov 2022 12:23:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> 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
>
> src/hotspot/share/utilities/elfFile.cpp line 1651:
> 
>> 1649:   int bytes_written = jio_snprintf(dst, count, "%s", src);
>> 1650:   // Add null terminator.
>> 1651:   dst[count - 1] = '\0';
> 
> Does it make sense to return a truncated file name up to the caller of `DwarfFile::LineNumberProgram::get_filename_from_header()`? Will this not just confuse him? I think it makes more sense to cleanly handle truncation, and e.g. skip file parsing for dwarf files with too long names.

I think you're right that it's rather unexpected to get an incomplete filename back. But just silently skipping the filename might be confusing as well. We could either print an error (I guess that's useful either way but should only be printed with `TraceDwarfLevel`) or just return a generic "buffer overflow" string as filename instead if it fits into the provided filename buffer. And only if that's not possible we could silently skip the filename. Would that be an option?

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

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