mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-01-30 12:44:10 +08:00
80b56fad5c
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. |
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| contrib | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gdbserver | ||
| gdbsupport | ||
| gnulib | ||
| gold | ||
| gprof | ||
| include | ||
| intl | ||
| ld | ||
| libbacktrace | ||
| libctf | ||
| libdecnumber | ||
| libiberty | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| zlib | ||
| .cvsignore | ||
| .gitattributes | ||
| .gitignore | ||
| ar-lib | ||
| ChangeLog | ||
| compile | ||
| config-ml.in | ||
| config.guess | ||
| config.rpath | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| COPYING.LIB | ||
| COPYING.LIBGLOSS | ||
| COPYING.NEWLIB | ||
| depcomp | ||
| djunpack.bat | ||
| install-sh | ||
| libtool.m4 | ||
| lt~obsolete.m4 | ||
| ltgcc.m4 | ||
| ltmain.sh | ||
| ltoptions.m4 | ||
| ltsugar.m4 | ||
| ltversion.m4 | ||
| MAINTAINERS | ||
| Makefile.def | ||
| Makefile.in | ||
| Makefile.tpl | ||
| makefile.vms | ||
| missing | ||
| mkdep | ||
| mkinstalldirs | ||
| move-if-change | ||
| multilib.am | ||
| README | ||
| README-maintainer-mode | ||
| setup.com | ||
| src-release.sh | ||
| symlink-tree | ||
| test-driver | ||
| ylwrap | ||
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.