[PATCH] D64750: [llvm-readelf] - Remove the precompiled binary from gnu-hash-symbols.test.

[George Rimar via Phabricator via llvm-commits]

grimar marked an inline comment as done.
grimar added inline comments.


================
Comment at: test/tools/llvm-readobj/elf-hash-symbols.test:48
+      - Tag:   DT_GNU_HASH
+## 0x2C + PT_LOAD's p_offset == offset of .gnu.hash
+        Value: 0x000000000000002C
----------------
grimar wrote:
> grimar wrote:
> > MaskRay wrote:
> > > jhenderson wrote:
> > > > Perhaps you should explain what 0x2C is (I think it's the size of .hash, right?)
> > > > PT_LOAD's p_offset
> > > 
> > > Nit: I think the usage here is a bit unusual. Normally a `PT_DYNAMIC` is created to contain `.dynamic` and at runtime the rtld decodes `.dynamic` entries by finding the `PT_DYNAMIC` address.
> > > 
> > > Maybe you can create a PT_DYNAMIC to make the test look more reasonable?
> > > 
> > > If you decide to do that, delete `- Section: .dynamic` from the `PT_LOAD`.
> > > 
> > I expanded the comment to reveal the full picture of how the computation happen.
> > 
> > Note that in this test case both `.hash` and `.gnu.hash` have section VAs = 0
> > (yaml2obj doesn't set it). So I tried to explain the underhood without using
> > a wordings like "address of hash section".
> >> Nit: I think the usage here is a bit unusual. Normally a PT_DYNAMIC is created to contain .dynamic and at runtime the rtld decodes .dynamic entries by finding the PT_DYNAMIC address.
> 
> But we are testing here the logic of `llvm-readelf`. It does not need `PT_DYNAMIC` to dump the hash tables.
Moreover, I think we could improve dumper to be able to dump these section even without any `.dynamic` section at all.
They have the unique types: `SHT_HASH` and `SHT_GNU_HASH`. It should be possible do do that.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64750/new/

https://reviews.llvm.org/D64750