Here is a patch for readelf raw .debug_macro reading.
The output is like .debug_macinfo, but the format was different enough
to just add a new section parsing function. The vendor extension opcode
table code isn't really tested since there are no examples out there yet.
But I had some idea for some extensions, so I might just add those as
an GCC vendor extensions and see if the opcode table code does the right
thing.
There is a little testcase that shows the output format.
On Tue, Jun 26, 2012 at 12:13:44PM +0200, Mark Wielaard wrote:
The new define/undef and start_file/end_file opcodes encode the same
information (and use the same values). There is no vendor_ext. There are
three new opcodes define_indirect, undef_indirect and
transparent_include. The first two are identical to define/undef, but
take their arguments differently. And transparent_include makes it
possible to reuse opcodes from somewhere else in the section. These
seems to be just the kind of thing that our interface wants to hide from
the user. So we would just return the original DW_MACINFO_define opcode
numbers and provide the param1/2 as we do now (just fetch them from
different places). Does that sound like a plan?
This plan doesn't seem possible :{
The new .debug_macro format has headers that need to be stored.
We could put that into the Dwarf_CU like we do for the line info.
But the transparent_include opcode can reference .debug_macro sections
that have their own headers (but don't necessarily have to be hooked off
any CU). In dwarf_getmacros () we only have a ptrdiff_t to track state.
But since there are transparent_includes (which can be nested) from which
we would need to return I don't think we can reuse this interface. We
could just return the "raw" transparent_include, but that doesn't do the
user any good since there is no way to reference such a "dangling"
(not connected to a CU) macro section. Or does anybody have a really
smart idea to do so anyway?
Cheers,
Mark