[PATCH] D59186: [llvm-readobj] Separate `Symbol Version` dumpers into `LLVM style` and `GNU style`

Xing via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 18 20:00:44 PDT 2019


Higuoxing updated this revision to Diff 191235.
Higuoxing added a comment.

Addressed @jhenderson 's comments

> It may be worth factoring out this->dumper() into a local variable, since you use it in a number of places.

Done

> I know this was there before, but report_fatal_error is not a good way of reporting errors, since it implies an internal bug in LLVM. It should

report a normal parse error or similar in the same way as other errors in llvm-readobj.
I would like to fix this issue here and that in `LLVM style dumper`

I implemented 3 dumpers for `.gnu.version`, `.gnu.version_r`, `.gnu.version_d`, with some small adjustments.

- `GNU readelf` treats `0x0` flags as `none`, so I add one in `SymVersionFlags`
- I separate `getSymbolVersion` into `getSymbolVersion` and `getSymbolVersionByIndex`. Because when dumping `.gnu.version` section, we should print

symbol version for symbols that have valid version name.

However, there are some issues.

- Currently, when dumping `.gnu.version_d` section, we assume a symbol can have only one predecessor. But `GNU readelf` could dump these predecessors

correctly.

- When dumping some fields that contains offset into string table, if the offset is invalid, `GNU readelf` could give warning, and give the malformed

value.

Shall I separate this patch into several small patches?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D59186

Files:
  test/tools/llvm-readobj/elf-versioninfo.test
  test/tools/yaml2obj/verdef-section.yaml
  test/tools/yaml2obj/verneed-section.yaml
  test/tools/yaml2obj/versym-section.yaml
  tools/llvm-readobj/ELFDumper.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D59186.191235.patch
Type: text/x-patch
Size: 34978 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190319/b69b5c4f/attachment.bin>


More information about the llvm-commits mailing list