On Thu, 22 Oct 2026 15:41:18 GMT, Andrei Pangin <[email protected]> wrote:
>> src/hotspot/share/jfr/recorder/stacktrace/jfrNativeFunctionRepository.cpp
>> line 164:
>>
>>> 162: const char* desc = name + align_up(nhdr->n_namesz, 4);
>>> 163: pos = desc + align_up(nhdr->n_descsz, 4);
>>> 164: if (pos > end) {
>>
>> I think it's fine that we assume the alignment is always 4. I check
>> libjvm.so linked by gcc and clang. it's always 4 for.note.gnu.build-id.
>>
>> but there's a corner case that n_descsz is not multiple of 4.
>> Let's say --build_id=0x123456, so descsz=3. it will round up to 4 at line
>> 163.
>>
>> If `.note.gnu.build-id` happens to be the last section, this code will exit
>> early at 165 because pos + 4 > end. We miss the valid build_id.
>>
>> We somehow need to execute 168-177 first before bumping pos.
>>
>> here is the similar logic in santizer-common.
>> https://github.com/llvm/llvm-project/blob/a808f8ea7fdc61ead417bfe55e8ef5f728776aeb/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp#L742-L766
>
> 4-byte alignment is required by
> [gABI](https://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_section).
> If the size of a Note Section happens to be not multiple of 4, `readelf`
> will warn about an invalid note:
>
> readelf: Warning: note with invalid namesz and/or descsz found at offset 0
> readelf: Warning: type: 0x3, namesize: 0x4, descsize: 0x3, alignment: 4
>
> I can modify code to accept non-conformant notes (it's a trivial change), but
> this won't have any practical impact as all standard build-ids (MD5, SHA1,
> UUID) are multiple of 4.
I agree that most of projects are using named schemes: md5, sha1, tree. They
are all multiple of 4.
but I do find some projects use custom build_ids, such as git/hg commit, or
unnamed scheme.
https://github.com/search?q=%22--build-id%3D0x%22&type=code
it's also future-proof.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32524#discussion_r4350828099
