Page MenuHomeFreeBSD

readelf: add support for ELF package metadata note
ClosedPublic

Authored by emaste on Nov 12 2024, 2:45 PM.
Tags
None
Referenced Files
F167486069: D47524.id146317.diff
Sat, Aug 22, 4:33 AM
Unknown Object (File)
Thu, Aug 13, 1:33 AM
Unknown Object (File)
Wed, Aug 12, 8:45 PM
Unknown Object (File)
Wed, Aug 12, 5:41 PM
Unknown Object (File)
Tue, Aug 11, 6:42 AM
Unknown Object (File)
Tue, Aug 11, 12:49 AM
Unknown Object (File)
Mon, Aug 10, 8:21 PM
Unknown Object (File)
Mon, Aug 10, 11:57 AM
Subscribers

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

emaste created this revision.
fuz added inline comments.
contrib/elftoolchain/readelf/readelf.c
3838

Can we get a symbolic constant for this type?

3841–3842

Cast to avoid sign-extension, clearer code. Is the charset of these ASCII? Or is it UTF-8?

The general idea seems fine.

Selfishly, it's convenient to see someone else driving a need for JSON handling in ELF files since we're going to want something like that for CHERI compartmentalization. CC @jhb

contrib/elftoolchain/readelf/readelf.c
3841–3842

From the systemd.io link "The format is a single JSON object, encoded as a zero-terminated UTF-8 string". We should probably act accordingly.

contrib/elftoolchain/readelf/readelf.c
3838
3841–3842

Yes, although it seems we need some generalized safe UTF-8 printing function. GNU readelf just passes it to printf %s.

contrib/elftoolchain/readelf/readelf.c
3841–3842

Scratch that, my code is still wrong. buf is a const char *, so buf[i] can be negative. The isprint call should be isprint((unsigned char)buf[i]).

For more comprehensive support, we could call iconv to transcode the buffer contents into the current locale.

use strvisx to handle possibly bogus UTF-8

Good iea using strvisx.

This revision is now accepted and ready to land.Jun 10 2026, 6:00 PM