Page MenuHomeFreeBSD

readelf: add support for ELF package metadata note
AcceptedPublic

Authored by emaste on Nov 12 2024, 2:45 PM.
Tags
None
Referenced Files
F159473436: D47524.diff
Sun, Jun 14, 3:01 PM
Unknown Object (File)
Tue, May 26, 9:37 PM
Unknown Object (File)
Tue, May 26, 9:27 PM
Unknown Object (File)
Tue, May 26, 12:26 PM
Unknown Object (File)
Tue, May 26, 12:21 PM
Unknown Object (File)
May 2 2026, 12:49 PM
Unknown Object (File)
May 1 2026, 9:25 AM
Unknown Object (File)
Apr 28 2026, 12:04 PM
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.Wed, Jun 10, 6:00 PM