[PATCH] D93209: [libObject, llvm-readobj] - Reimplement `ELFFile<ELFT>::getEntry`.

George Rimar via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 15 00:48:48 PST 2020


grimar added inline comments.


================
Comment at: llvm/test/tools/llvm-nm/invalid-symbol-table-size.test:6
 # RUN: yaml2obj -DBITS=32 -DSIZE=33 -DDYNSIZE=32 %s -o %t.32-bit.o
-# RUN: not llvm-nm %t.32-bit.o 2>&1 | FileCheck -DSIZE=33 -DSYMSIZE=16 -DINDEX=2 %s
+# RUN: not --crash llvm-nm %t.32-bit.o 2>&1 | FileCheck -DSIZE=33 -DSYMSIZE=16 -DINDEX=2 %s
 # RUN: yaml2obj -DBITS=64 -DSIZE=49 -DDYNSIZE=48 %s -o %t.64-bit.o
----------------
jhenderson wrote:
> Seems to me like this change is a regression on the old behaviour? Same with llvm-objdump and llvm-size. Please don't land it with this.
This is because of the following code in `llvm/Object/ELFObjectFile.h`

```
  const Elf_Sym *getSymbol(DataRefImpl Sym) const {
    auto Ret = EF.template getEntry<Elf_Sym>(Sym.d.a, Sym.d.b);
    if (!Ret)
      report_fatal_error(Ret.takeError());
    return *Ret;
  }
```

Previously `getEntry<Elf_Sym>` ignored this error
Now it started to call `report_fatal_error` right here.

Ideally, we should never call `report_fatal_error`. I am also not sure I can call it a regression,
because the code had this call before my change too. I.e. I believe it might report `LLVM ERROR`
for another broken input already. It is just a luck that it "worked".
And the root of the issue is in `Elf_Sym *getSymbol`, which should return `Expected<>` I think.

Do you want me to update the `getSymbol` first?


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

https://reviews.llvm.org/D93209



More information about the llvm-commits mailing list