This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Recognize .debug_macro/DW_AT_GNU_macros


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

Attachment: 0001-readelf-Add-.debug_macro-parsing-support.patch
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]