[all-commits] [llvm/llvm-project] 25e437: [llvm-readobj/elf] - Ignore the hash table when on...

Georgii Rymar via All-commits all-commits at lists.llvm.org
Mon Oct 12 02:13:53 PDT 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 25e437ec1e5b96028a319d3f2aca4129cdd3d85d
      https://github.com/llvm/llvm-project/commit/25e437ec1e5b96028a319d3f2aca4129cdd3d85d
  Author: Georgii Rymar <grimar at accesssoftek.com>
  Date:   2020-10-12 (Mon, 12 Oct 2020)

  Changed paths:
    M llvm/test/tools/llvm-readobj/ELF/hash-table.test
    M llvm/tools/llvm-readobj/ELFDumper.cpp

  Log Message:
  -----------
  [llvm-readobj/elf] - Ignore the hash table when on EM_S390/EM_ALPHA platforms.

Specification for `SHT_HASH` table says (https://refspecs.linuxbase.org/elf/gabi4+/ch5.dynamic.html#hash)
that it contains `Elf32_Word` entries for both `32/64` bit objects.

But there is a problem with `EM_S390` and `ELF::EM_ALPHA` platforms: they use 8-bytes entries.
(see the issue reported: https://bugs.llvm.org/show_bug.cgi?id=47681).

Currently we might infer the size of the dynamic symbols table from hash table,
but because of the issue mentioned, the calculation is wrong. And also we don't dump the hash table
properly.

I am not sure if we want to support 8-bytes entries as they violates specification and also the
`.hash` table is kind of deprecated by itself (the `.gnu.hash` table is used nowadays).
So, the solution this patch suggests is to ban using of the hash table on `EM_S390/EM_ALPHA` platforms.

Differential revision: https://reviews.llvm.org/D88817




More information about the All-commits mailing list