Hi,
On Fri, 2012-04-27 at 23:03 -0700, Roland McGrath wrote:
> That would be great. But I'm thinking whether we don't
need (in
> addition to publishing the generator macros) a stringifying interface as
> part of ABI.
Agreed. We held off before because we thought the C++ interface was
going to become usable soon enough, and we have it there already in
fairly nice ways. But it never did, and there are C consumers to
consider too. Incidentally, it looks like gcc's libiberty just added
exactly this in the last few days.
We need to merge the generator stuff into the implementation first,
since obviously we don't want just to move the manually-maintained
readelf.c tables into manually-maintained libdw tables.
Then we just have to decide on the exact interfaces, which shouldn't
be too hard.
I started that work on the mjw/dwarfstrings branch (also attached).
This first patch moves dwarfstrings under libdw, adds the new functions
to libdw[.h|.map] and updates readelf.c and some tests to use the new
functions.
I did make some small changes from the dwarf branch versions. The
functions now only return the string if the code is known, otherwise
they return NULL. This allows the functions to be used to check whether
a code actually exists/is known, makes it possible for the caller to
handle unknown codes themselves (I updated readelf to consistently use
unknown_foobar_0xhexnum) and makes the functions trivially thread-safe,
otherwise we would have to generate strings in some (thread-local)
buffer.
How does it look so far?
If this interface looks OK, the next step would be to add an extra test
to exhaustively use them all (as self tests) to make sure the tables are
complete (at least for the toolchain used to produce DWARF for our own
code) generate all tables through known-dwarf.h macros (some might have
big gaps in them, so we probably shouldn't generate arrays for all of
them).
Cheers,
Mark