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
F163955954: D47524.id181710.diff
Mon, Jul 27, 11:10 AM
Unknown Object (File)
Sun, Jul 26, 10:02 AM
Unknown Object (File)
Sat, Jul 25, 8:34 PM
Unknown Object (File)
Sat, Jul 25, 3:18 AM
Unknown Object (File)
Sat, Jul 18, 11:16 AM
Unknown Object (File)
Wed, Jul 15, 6:36 AM
Unknown Object (File)
Wed, Jul 15, 6:36 AM
Unknown Object (File)
Thu, Jul 9, 12:32 AM
Subscribers

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

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

Can we get a symbolic constant for this type?

3840–3841

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
3840–3841

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
3837
3840–3841

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
3840–3841

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