]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit - binutils/readelf.c
binutils: make objdump/readelf --ctf-parent actually useful
authorNick Alcock <nick.alcock@oracle.com>
Mon, 25 Oct 2021 10:17:02 +0000 (11:17 +0100)
committerNick Alcock <nick.alcock@oracle.com>
Mon, 25 Oct 2021 10:17:03 +0000 (11:17 +0100)
commit80b56fad5c99a8c93004b0432dd2b363125de35a
treec6a84af02a9c4678a620175ac3e569dd8c4b33d6
parent5513527b59e95a53802b5960821aa3c98a280ac8
binutils: make objdump/readelf --ctf-parent actually useful

This option has been present since the very early days of the
development of libctf as part of binutils, and it shows.  Back in the
earliest days, I thought we might handle ambiguous types by introducing
new ELF sections on the fly named things like .ctf.foo.c for ambiguous
types found only in foo.c, etc.  This turned out to be a terrible idea,
so we moved to using a CTF archive in the .ctf section which contained
all the CTF dictionaries -- but the --ctf-parent option in objdump and
readelf was never adjusted, and lingered as a mechanism to specify CTF
parent dictionaries in sections other than .ctf, even though the linker
has no way to produce parent dictionaries in different sections from
their children, libctf's ctf_open can't handle such split-up
parent/child dicts, and they are never found in the wild, emitted by GNU
ld or by any known third-party linking tool.

Meanwhile, the actually-useful ctf_link feature (albeit not used by ld)
which lets you remap the names of CTF archive members (so you can end up
with a parent archive member named something other than ".ctf", still
contained with all its children in a single .ctf section) had no support
in objdump or readelf: there was no way to tell them that these members
were parents, so all the types in the associated child dicts always
appeared corrupted, referencing nonexistent types from a parent objdump
couldn't find.

So adjust --ctf-parent so that rather than taking a section name it
takes a member name instead (if not specified, the name is ".ctf", which
is what GNU ld emits).  Because the option was always useless before
now, this is expected to have no backward-compatibility implications.

As part of this, we have to slightly adjust the code which skips the
archive member name if redundant: right now it skips it if it's ".ctf",
on the assumption that this name will almost always be at the start
of the objdump output and thus we'll end up with a shared dump
and then smaller, headed dumps for the per-TU child dicts; but if
the parent name has been changed, that won't be true any more.

So change the rules to "members named .ctf which appear first in the
first have their member name skipped".  Since we now need to count
members, move from ctf_archive_iter (for which passing in extra
parameters requires defining a new struct and is clumsy) to
ctf_archive_next, allowing us to just *call* dump_ctf_archive_member and
maintain a member count in the obvious way.  In the process we fix a
tiny difference between readelf and objdump: if a ctf_dump ever failed,
readelf skipped every later member, while objdump tried to keep going as
much as it could.  For a dumping tool the former is clearly preferable.

binutils/ChangeLog
2021-10-25  Nick Alcock  <nick.alcock@oracle.com>

* objdump.c (usage): --ctf-parent now takes a name, not a section.
(dump_ctf): Don't open a separate section; use the parent_name in
ctf_dict_open instead.  Use ctf_archive_next, not ctf_archive_iter,
so we can pass down a member count.
(dump_ctf_archive_member): Add the member count; don't return
anything.  Import parents into children no matter what the
parent's name, while still avoiding displaying the header for the
common parent name of ".ctf".
* readelf.c (usage): Adjust similarly.
(dump_section_as_ctf): Likewise.
(dump_ctf_archive_member): Likewise.  Never stop iterating over
archive members, even if ctf_dump of one member fails.
* doc/ctf.options.texi: Adjust.
binutils/ChangeLog
binutils/doc/ctf.options.texi
binutils/objdump.c
binutils/readelf.c