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]

2009-07-27 Status


Last week
---------

Time spent on elfutils: 80%

* That was mostly output.  The approach to handling physical Elf file is 
to take the original Elf file, drop all the debug sections, and 
reintroduce them rebuilt.
   ** I took the stripping code from strip.c, made it more C++-y (e.g. 
dropped inline functions) and dropped lots of stuff that I don't need 
(e.g. separate debuginfo).
   ** I introduced some bits to make it simple to add more debuginfo 
sections in the file.
   ** At the end of the week, I was able to produce a nice .debug_abbrev 
with a "blah" string in it.  Yay, I guess, although I'd hoped to have 
something more substantial.
   ** Nothing done on relocations yet.  They don't even get dropped. 
I'm afraid that the strip logic simply won't even remove the debug 
sections since reloc sections keep referencing them, but I didn't try.

* I've fixed a couple bugs in dwarflint that I hit as I tried to 
validate ELFs broken in various ways.  Also added a new check or two.

This week
---------

Time scheduled for elfutils: 80%

* I just committed bits that I've done during odd moments of the weekend 
and today before now.  It currently emits .debug_abbrev with canonical 
forms (i.e. no compression done at all).
   ** The code is written so that it should be simple to build several 
abbreviations from one shape (so that you could partition DIEs of one 
shape to e.g. those whose values fit into someform_2 and those that need 
someform_4).  That may actually be too expensive to implement though 
(runtime-wise), for big die trees, and I'm afraid the gain won't be that 
big.

* Next I'd like to have it emit .debug_info.  My current thinking is as 
follows:
   ** First grab my trusty Dwarf spec and read through it making sure 
that what's below makes some sense.
   ** Start by building a separate binary blob for each DIE, with some 
pieces uninitialized (references to other dies), but with enough space 
reserved for that information.
   ** I think I'll need to create one DW_AT_partial_unit per unique die 
(except for DW_AT_compile units which are left as are).
      *** Figure out how to find out that the sub-tree should be emitted 
as-is, and not fragmented further.  Probably something with number of 
sharees and size of DIE.  I.e., does it pay off to wrap the die in 
partial unit?
   ** Then I assemble all the pieces.  During assembly, all references 
to other dies are translated to DW_AT_imported_unit DIEs.  Now that I 
know where each DIE is, I do second pass and fill in DIE addresses.
   ** One thing that I'm afraid of is that the size necessary for 
certain attributes turns out to depend on layout of DIEs.

* If I get this done by Friday, I'll start on optimizing .debug_abbrev. 
  To get one optimal abbrev per shape should be easy.

PM

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