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-08-24 Status


Last 2 weeks
------------

Time spent on elfutils: 60-70%

Work on output.
    * Small fixes etc.
    * Output of VS_constant blocks
    * Allow recomputation of back-patches.  Used to emit correct 
CU-local references, the recomputation being a simple subtraction of CU 
offset from the patch value.
    * Now generates abbreviations.  Currently one abbrev per unique DIE, 
no merging is done.  The best available form is picked for attributes 
that we _can_ optimize (e.g. constants, flags, data, but e.g. not 
references, since we don't know how the DIEs will end up being laid out. 
  Also not strings, that will need string gathering pass).
    * Merged in `dwarf' branch with Roland's work.

And dwarflint:
    * Rewrite of read_die_chain value validation.  The amount of code is 
roughly the same, but the code is more extensible and clearer.
    * Support DW_FORM_sec_offset, DW_FORM_flag_present from DWARF4

It's all on pmachata/dwarf-writer.

This week
---------

My vague plan for what to do next revolves around figuring out how to do 
the low-level optimization properly.  There are some moving parts that 
influence each other.  For example, whether it is advantageous to emit 
string as strp vs. inline string depends on how many times does this 
string appear, and thus depends on the way we do the dissection of the 
DIE tree into partial CUs.  On the other hand, the decision whether it 
is advantageous to dissect a DIE sub-tree into own partial unit, is 
dependent on forms that we use to store the attributes, and therefore 
links back to the string/strp problem.  There are more instances of this 
problem pattern.  Or perhaps there's a certain point where dissecting 
the tree is always advantageous, and this can be used as a starting 
point in some sort of iterative approach.

Oh, and everything is still coded with xxx instead of proper dwarf_64 
handling.  We never do the 32-to-64-bit transition.  I think that DWARF 
files that big won't really be common, I wonder if there are any in 
Fedora at all.  We can take the approach of trying to emit it 32-bit, 
and when we find that we can't encode some DIE reference in 32bit 
quantity, we simply restart the process with dwarf_64 == true.  There 
will be a command-line switch for users who know that their files don't 
fit 32-bit limit, that will also be useful for testing emitting and 
consumption of 64-bit DWARF files.

PM

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