Re: Status 2009-02-10

[Roland McGrath <roland at redhat dot com>]

>        * Relocations.  Some half-baked code is in the repository 
> already, but it's missing features and is probably buggy.  It's also 
> progressing slower than I'd like, the landscape is less familiar than I 
> thought it would be.  But I think I'll be able to get it done by tomorrow.

I would reduce them all in the initial scan rather than consulting the
actual Rel/Rela fields again later (just preserve the index for each one to
identify it when complaining about a reloc).

Reduce the type to DW_FORM_data[48], these are the only actual possibilities.
(relocate.c handles ELF_T_HALF too just because it's trivial, but it is never
used in DWARF sections really.)

For REL flavor, you have to fetch addend with read_[48]ubyte_unaligned on
the sh_info section's d_buf + r_offset, in lieu of r_addend from RELA.  
I'd be inclined to do this in the initial scan just so that the REL/RELA
distinction is gone for all the later code and in your data structures.

Whatever is nonobvious about the reloc area, please ask.  The reloc stuff
that applies to DWARF is all quite straightforward, so I'm sure I can make
it more familiar-seeming quickly if you have questions.

>        * With a bit of luck, I may get around to start hacking on 
> expected-trees high level check.  (Planning this arbitrarily, because 
> Mark Wielaard asked me about the low-pc-less DW_TAG_label last week.)

Ok.  A place to start is a table based on Appendix A.  For each tag,
some attrs are "required" (bogus if missing), some "expected" (suspicious
if missing), some "optional", and it's worthy of mention if any others appear.
Likewise for the tags appearing as children of each tag, but that can be a
later step.

However, I don't want this to sop up much time before we are solid on all
the lower-level checks, including relocs.  (This isn't stuff that helps
directly with the writer and compression projects, it's just good stuff for
diagnosing compiler issues.)  So hack as you will, but if it becomes a big
push taking days of time, it's not the right thing to push on first.

>        * Or maybe do a bit of C++ification, even though I would have to 
> fix a temporary solution for all the X-to-string tables.  But that's 
> really a quick routine task.

There is nothing wrong with part of the program being in C and another part
in C++.  So to do this for its own sake is just make-work, and moreso if it
requires temporary hacks for unfinished C++ stuff like the name tables.  We
can do the proper name stuff soon enough.  Don't put any priority on this
unless you decide some code is better done using C++ containers than ad hoc
in C or something specifically useful like that.

>        * Still didn't get around to go through anomalies we've found, 
> leaving it for next coding-quota overrun.

There is no hurry on that, we just don't want to forget anything we've
learned already.  When we have the tool in good shape, we will run it
across the big data set and then can do focussed effort to classify the
anomalies and follow them up.


Thanks,
Roland