This teaches the tools to parse and dump
the .dynamic section and its dynamic tags.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
@amontanez has already put something similar up for review here as D56569.
There was a corresponding llvm-dev email thread to discuss it further here:
http://lists.llvm.org/pipermail/llvm-dev/2019-January/129231.html
which didn't get much traction.
Interesting. I did not see it. D56569 seems to do a lot of different things.
FTR, my main intentions were the following:
- I looked how to dump/parse ELF versioning sections and found we sometimes might want to access
the dynamic tags values. For example:
DT_VERDEFNUM The number of entries in DT_VERDEF.
DT_VERNEEDNUM The number of entries in DT_VERNEED.
- I noticed that some of our tests (For example, "binary-read-bad-vaddr.test" and lots of others improved by this patch)
want to see the particular tags and values and there was no way to do that (without editing the raw binary section content).
So I decided to implement the simple solution that would allow accessing and changing the dynamic entries from yaml and the code.
I think this is a good change -- it seems like it does the right thing and works as a good starter to add more fields. James, are you okay with this change?
This change basically looks fine in itself. From what I remember of the discussion around D56569, there isn't anything here in the behaviour that conflicts with that change, I believe.
lib/ObjectYAML/ELFYAML.cpp | ||
---|---|---|
677 ↗ | (On Diff #185055) | I may be missing something, but why is this line different to the equivalent for e.g. the relocations above? |
test/tools/llvm-readobj/gnu-hash-symbols.test | ||
77 ↗ | (On Diff #185055) | Not that it really matters, but any particular reason you've moved this to before the Link field? |
lib/ObjectYAML/ELFYAML.cpp | ||
---|---|---|
677 ↗ | (On Diff #185055) | See how relocations are declared. For example in ELFRelocs/RISCV.def: ELF_RELOC(R_RISCV_NONE, 0) ELF_RELOC(R_RISCV_32, 1) ... But dynamic tags are refined without prefix DT_*: DYNAMIC_TAG(NULL, 0) // Marks end of dynamic array. DYNAMIC_TAG(NEEDED, 1) // String table offset of needed library. ELF.h declares an enum like that: enum { #define DYNAMIC_TAG(name, value) DT_##name = value, #include "DynamicTags.def" #undef DYNAMIC_TAG }; (https://github.com/llvm-mirror/llvm/blob/master/include/llvm/BinaryFormat/ELF.h#L1242) Do I had to use ELF::DT_##X. The reason I used STRINGIFY and STRINGIFY(DT_##X) is that I think we should dump
DT_NULL is more clear than just NULL and so on. |
test/tools/llvm-readobj/gnu-hash-symbols.test | ||
77 ↗ | (On Diff #185055) | No. I had to use yaml2obj with the old YAMLs to convert then objects to a new YAML format (to update the tests), |
Oof, my email filters somehow didn't send the discussion here to my inbox. Sorry! I'm fine with this landing as-is, I can just rebase on top of it. I think the only significant deviance from the RFC is future improvements require that DynamicEntry::Val is a StringRef instead of llvm::yaml::Hex64, but I can address that later.