This is the mail archive of the
mailing list for the binutils project.
Re: [RFC] extending bfd_print_private_bfd_data
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
backend and parsing them all and passing them back one at a time
backend, why not go that little way further and build a word full of
instead? It would save all the bfd_print_private_bfd_data
filling up with lots of ugly strcmps if they could just check a
This requires table to translate names to flag bits. But I am not
that this is easy to do because
some print_private_bfd_data calls a more generic version of it (eg:
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
subtype names that the backend returns. So maybe in the PE backend
(completely made-up example with just realistic-sounding names):
#define PE_PRIVATE_DATA_SUBTYPE_NAMES \
#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
wouldn't even justify the effort of using a .def file and some macro
to generate both the string and flag definitions from the same
single list of
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;
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
list of words?
No I don't plan that.