[RFC] extending bfd_print_private_bfd_data

[Tristan Gingold-2]

Hi,

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).
ELF users don't have this issue because they can use readelf.

I'd like to enhance this feature.

 From a user point of view:
Add a new switch to objdump: -P xx, where xx is a word or a list of  
words separated by a comma.
The definition of the words are back-end specific.
  'objdump -p' will be equivalent to 'objdump -P all'.
  'objdump --help' will display the list of words and their meanings.

 From a bfd point a view:
Add new parameter 'const char *what' to bfd_print_private_bfd_data, to  
describe what has to be displayed.
WHAT should only be a word (ie the handling of a list of words is done  
by objdump).
If the word is not recognized by print_private_bfd_data, then FALSE  
must be returned.
In order to simplify the transition, NULL will be used to print  
everything.  Therefore the minimal code to
be added to all bfd back-end is something like:

   if (what != NULL)
     return FALSE;

Finally, back-ends that recognize non-NULL WHAT must also recognize  
"help".  In this case the documentation
for all words is displayed.

If this feature and this design is accepted, I will make a patch to  
transition all back-ends.

Comments are welcome,
Tristan.

[Dave Korn-6]

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

  I do find myself using "objdump -p | grep" quite a lot to extract a single
field.

> From a user point of view:
> Add a new switch to objdump: -P xx, where xx is a word or a list of
> words separated by a comma.
> The definition of the words are back-end specific.

> Add new parameter 'const char *what' to bfd_print_private_bfd_data, to
> describe what has to be displayed.
> WHAT should only be a word (ie the handling of a list of words is done
> by objdump).
> If the word is not recognized by print_private_bfd_data, then FALSE must
> be returned.

> Comments are welcome,

  As long as you're going to the lengths of accepting a list of names from the
backend and parsing them all and passing them back one at a time to the
backend, why not go that little way further and build a word full of flag bits
instead?  It would save all the bfd_print_private_bfd_data routines from
filling up with lots of ugly strcmps if they could just check a bitmask.

    cheers,
      DaveK

[Tristan Gingold-2]

On Nov 4, 2009, at 4:05 PM, Dave Korn wrote:

>  As long as you're going to the lengths of accepting a list of names  
> from the
> backend and parsing them all and passing them back one at a time to  
> the
> backend, why not go that little way further and build a word full of  
> flag bits
> instead?  It would save all the bfd_print_private_bfd_data routines  
> from
> filling up with lots of ugly strcmps if they could just check a  
> bitmask.

This requires table to translate names to flag bits.  But I am not  
sure that this is easy to do because
some print_private_bfd_data calls a more generic version of it (eg:  
elf).
Maybe you have a nice idea to implement such a table ?

If you want to use flag bits, we could create one or two helpers that  
does the work (one for converting
a word to a flag, and the other to generate the help).

Tristan.

[Dave Korn-6]

Tristan Gingold wrote:

>
> On Nov 4, 2009, at 4:05 PM, Dave Korn wrote:
>
>>  As long as you're going to the lengths of accepting a list of names
>> from the
>> backend and parsing them all and passing them back one at a time to the
>> backend, why not go that little way further and build a word full of
>> flag bits
>> instead?  It would save all the bfd_print_private_bfd_data routines from
>> filling up with lots of ugly strcmps if they could just check a bitmask.
>
> This requires table to translate names to flag bits.  But I am not sure
> that this is easy to do because
> some print_private_bfd_data calls a more generic version of it (eg: elf).
> Maybe you have a nice idea to implement such a table ?

  I figured that there could be just a very simple convention: assign
successive flag bits starting at 0 to successive words in the string of -P
subtype names that the backend returns.  So maybe in the PE backend we'd write
(completely made-up example with just realistic-sounding names):

#define PE_PRIVATE_DATA_SUBTYPE_NAMES \
        "imagebase,symboltable,characteristics,checksum"

#define PE_PRIVATE_DATA_FLAG_IMAGEBASE (1<<0)
#define PE_PRIVATE_DATA_FLAG_SYMBOLTABLE (1<<1)
#define PE_PRIVATE_DATA_FLAG_CHARACTERISTICS (1<<2)
#define PE_PRIVATE_DATA_FLAG_CHECKSUM (1<<3)

and that would be that; it probably would be easy enough to maintain that it
wouldn't even justify the effort of using a .def file and some macro trickery
to generate both the string and flag definitions from the same single list of
entries.

  Or were you planning that some backends might dynamically generate their
list of words?  It wouldn't be nearly so clean in that case, I was thinking
that each backend was just going to have a "const char *" somewhere.

    cheers,
      DaveK

[Tristan Gingold-2]

On Nov 4, 2009, at 4:25 PM, Dave Korn wrote:

> Tristan Gingold wrote:
>>
>> On Nov 4, 2009, at 4:05 PM, Dave Korn wrote:
>>
>>> As long as you're going to the lengths of accepting a list of names
>>> from the
>>> backend and parsing them all and passing them back one at a time  
>>> to the
>>> backend, why not go that little way further and build a word full of
>>> flag bits
>>> instead?  It would save all the bfd_print_private_bfd_data  
>>> routines from
>>> filling up with lots of ugly strcmps if they could just check a  
>>> bitmask.
>>
>> This requires table to translate names to flag bits.  But I am not  
>> sure
>> that this is easy to do because
>> some print_private_bfd_data calls a more generic version of it (eg:  
>> elf).
>> Maybe you have a nice idea to implement such a table ?
>
>  I figured that there could be just a very simple convention: assign
> successive flag bits starting at 0 to successive words in the string  
> of -P
> subtype names that the backend returns.  So maybe in the PE backend  
> we'd write
> (completely made-up example with just realistic-sounding names):
>
> #define PE_PRIVATE_DATA_SUBTYPE_NAMES \
> "imagebase,symboltable,characteristics,checksum"
>
> #define PE_PRIVATE_DATA_FLAG_IMAGEBASE (1<<0)
> #define PE_PRIVATE_DATA_FLAG_SYMBOLTABLE (1<<1)
> #define PE_PRIVATE_DATA_FLAG_CHARACTERISTICS (1<<2)
> #define PE_PRIVATE_DATA_FLAG_CHECKSUM (1<<3)
>
> and that would be that; it probably would be easy enough to maintain  
> that it
> wouldn't even justify the effort of using a .def file and some macro  
> trickery
> to generate both the string and flag definitions from the same  
> single list of
> entries.

I can't figure out exactly how this would work with elf backends.  See  
for example elf32-m32c.c:

m32c_elf_print_private_bfd_data (bfd *abfd, PTR ptr)
{
   FILE *file = (FILE *) ptr;
   flagword flags;

   BFD_ASSERT (abfd != NULL && ptr != NULL);

   /* Print normal ELF private data.  */
   _bfd_elf_print_private_bfd_data (abfd, ptr);

   ...
}

In this case, the complete words string would be a concatenation of  
the one for _bfd_elf_print_private_bfd_data and the one for m32c.
But the flag value for m32c would depend on the number of words for  
the elf generic printer.  Doable but
more cryptic IMHO.

>  Or were you planning that some backends might dynamically generate  
> their
> list of words?

No I don't plan that.

Tristan.

[Dave Korn-6]

Tristan Gingold wrote:

> I can't figure out exactly how this would work with elf backends.  See
> for example elf32-m32c.c:
>
> m32c_elf_print_private_bfd_data (bfd *abfd, PTR ptr)
> {
>   FILE *file = (FILE *) ptr;
>   flagword flags;
>
>   BFD_ASSERT (abfd != NULL && ptr != NULL);
>
>   /* Print normal ELF private data.  */
>   _bfd_elf_print_private_bfd_data (abfd, ptr);
>
>   ...
> }

  Ah.  Derivation/inheritance.  Didn't allow for that.

> In this case, the complete words string would be a concatenation of the
> one for _bfd_elf_print_private_bfd_data and the one for m32c.
> But the flag value for m32c would depend on the number of words for the
> elf generic printer.  Doable but
> more cryptic IMHO.
>
>>  Or were you planning that some backends might dynamically generate their
>> list of words?
>
> No I don't plan that.

  Ah, no, but since there's implicit concatentation of strings going on there
by having one private print routine call the other... argh.  Yeh, can't be
done; best just let them parse the words themselves.  Ah well, it would have
been nice - but only if it had been practical and simpler than the alternative!

    cheers,
      DaveK

[Nick Clifton]

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 ?

I would be hesitant about adding new code to the BFD library when it is
not really needed.

Alternatively, is there a need for a new tool, say 'coffdump' to handle
the special needs of the COFF/PE format ?

Cheers
   Nick

[Tristan Gingold-2]

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.

[Nick Clifton]

Hi Tristan,

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

OK then, lats go ahead with this.

Cheers
   Nick