This is the mail archive of the
mailing list for the binutils project.
Re: [RFC] extending bfd_print_private_bfd_data
On Nov 5, 2009, at 4:42 PM, Nick Clifton wrote:
some formats (pe, coff, mach-o) may dump a lot of information with
'objdump -p'. This is somewhat boring
if you need only to dump a specific part of that (for example only
the characteristics of a PE file).
Is it really that hard to use grep or cut to extract the information
that you want ?
Also possible (of course), this is not very convenient. objdump -p
can generate *a lot* of info
(eg unwind tables, relocations...). You can use more/less but it is
still difficult to navigate with it and
then you loose grep.
I would be hesitant about adding new code to the BFD library when it
is not really needed.
This is not really adding new code, but making existing code more
flexible. Note that this concerns only
coff/pe and mach-o. For other targets I don't see such a need.
Alternatively, is there a need for a new tool, say 'coffdump' to
handle the special needs of the COFF/PE format ?
We could add coffdump and machodump but I don't really see the need to
create a new tool for every new
file format. This is somewhat against the whole purpose of bfd, and
these tools have to duplicate most of
the logic of objdump (eg handling archives). I much prefer to have
one tool as it is less code to maintain.
readelf is somewhat special as it doesn't use bfd to read the file.
It was written (IIRC) to be sure that
BFD is not wrong (but this is not really an issue for PE or mach-o as
we have third-party tools to check
that BFD is right).