> * 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 _______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
