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] |
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] |