This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] extending bfd_print_private_bfd_data

On Nov 5, 2009, at 4:42 PM, Nick Clifton wrote:

Hi Tristan,

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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]