Re: [RFC] extending bfd_print_private_bfd_data

[Tristan Gingold <gingold at adacore dot com>]

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

Tristan.