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
Unknown Object (File)
Fri, Jul 3, 4:56 AM
Unknown Object (File)
Thu, Jul 2, 10:45 PM
Unknown Object (File)
Sun, Jun 28, 10:57 PM
Unknown Object (File)
Wed, Jun 24, 8:36 PM
Unknown Object (File)
Tue, Jun 23, 2:43 AM
Unknown Object (File)
Fri, Jun 19, 6:28 AM
Unknown Object (File)
Fri, Jun 19, 6:25 AM
Unknown Object (File)
Fri, Jun 19, 4:51 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.Wed, Jun 10, 6:00 PM