[PATCH v2 00/19] libctf, and CTF support for objdump and readelf

Nick Alcock nick.alcock@oracle.com
Tue May 28 09:56:00 GMT 2019


On 28 May 2019, Nick Clifton verbalised:

> Hi Nick,
>
>   Sorry for the delay in reviewing.

No problem! Review bandwidth is scarce: I'm happy to get reviews at all.

>> Nick Alcock (19):
>>   include: new header ctf.h: file format description
>>   include: new header ctf-api.h
>>   libctf: lowest-level memory allocation and debug-dumping wrappers
>>   libctf: low-level list manipulation and helper utilities
>>   libctf: error handling
>>   libctf: hashing
>>   libctf: implementation definitions related to file creation
>>   libctf: creation functions
>>   libctf: opening
>>   libctf: ELF file opening via BFD
>>   libctf: core type lookup
>>   libctf: lookups by name and symbol
>>   libctf: type copying
>>   libctf: library version enforcement
>>   libctf: mmappable archives
>>   libctf: labels
>>   libctf: debug dumping
>>   libctf: build system
>>   binutils: CTF support for objdump and readelf
>
> Patch series approved (all of it) - please apply.

Thank you! -- though I don't have commit rights yet, so until someone
sees fit to grant me that someone else will have to do the actual push.
I also don't really know how one transforms the ChangeLogs in the commit
messages into actual ChangeLog files in the commits: do you really edit
every commit and add the ChangeLog changes to it by hand?

(I should of course rebase it first so it's not based on a months-old
checkout, and make sure that it still works after the rebase.)


On related matters: I presume nobody minds if I submit further
improvements that change the format to provide size reductions (quite
radical ones)? i.e. nobody minds if it's not set in stone yet? It's
still young in this form, after all.

For backward-compatibility, I propose to use the usual GNU rules, and
provide backward-compat for all formats "in the world" in any official
release version: so for now I'll keep the format version at v3 and any
format changes go into that, updating the v1/v2 -> v3 compat code at the
same time, until a release of GCC or the not-yet-written linker plugin
or *something* that generates CTF, whereupon the format is bumped to v4
and backward-compat code for v3 -> all future changes in v4 need to be
added as part of any future changes. The backward-compat stuff also
means that most things that generate CTF don't need to change when the
format changes: the linker plugin will bring the format up to date as
needed.

(As for something that generates CTF, the linker plugin is my next major
thing to attack. I'm just trying to shrink things a little first. It's
amazing how many obvious improvements show up when you get your code
properly reviewed.)

> I would however ask that you make two small additions:
>
>   * Please could you add an entry to the binutils/NEWS file,
>     mentioning this new feature of the binutils.

How's about

 * Add support for dumping types encoded in the Compact Type Format
   to objdump and readelf.

(Should we mention that this is a *new* CTF, not format-compatible with
existing ones? Should we mention that we haven't committed tools that
emit CTF yet? Should we mention the existence of the library itself
anywhere, even though it's not -- yet -- user-visible? I'm not sure.)

>   * Please could you add an entry to the binutils/MAINTAINERS
>     file, listing yourself, or someone else at Oracle, as the
>     maintainer for the CTF code.

Of course! Though, again, without commit access all I can do is propose
an entry for the top level and an entry for binutils/MAINTAINERS, which
may change if GCC portions of this get in.

The top-level entry gets added to

bfd/; binutils/; elfcpp/; gas/; gold/; gprof/; ld/; opcodes/; cpu/;

I think. For MAINTAINERS, I am happy to have added

CTF		Nick Alcock <nick.alcock@oracle.com>

> Thanks very much for contributing this code to the binutils project.

I'm not done yet! Though the linker plugin won't turn up immediately
since I still have to write it, it will turn up, and this stuff will
actually be useful. (I'll be doing a simple linker plugin without
deduplication first, and then adding deduplication.)

But this is the foundation. Nothing else is possible without it. So
thank you for the excellent review!



More information about the Binutils mailing list