Re: [RFC] extending bfd_print_private_bfd_data

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

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