[PATCH] D66358: [llvm-readobj] Fallback to PT_NOTE if file doesn't have sections

James Henderson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 19 02:22:00 PDT 2019


jhenderson added a comment.

Thanks for doing this. This was something on my radar too as an odd inconsistency.



================
Comment at: llvm/trunk/test/tools/llvm-readobj/gnu-notes.test:7
+# RUN: llvm-objcopy --strip-sections %t1.so %t1.stripped.so
+# RUN: llvm-readelf --notes %t1.stripped.so | FileCheck %s --check-prefix=GNU-STRIPPED --strict-whitespace --match-full-lines
+# RUN: llvm-readobj --notes %t1.stripped.so | FileCheck %s --check-prefix=LLVM-STRIPPED
----------------
Not that it matters that much, but I don't think you needed the --strict-whitespace and --match-full-lines, since the format would be the same as the unstripped case.


================
Comment at: llvm/trunk/test/tools/llvm-readobj/gnu-notes.test:72-75
+#      GNU-STRIPPED:Displaying notes found at file offset 0x00000040 with length 0x00000020:
+# GNU-STRIPPED-NEXT:  Owner                Data size 	Description
+# GNU-STRIPPED-NEXT:  GNU                  0x00000010	NT_GNU_BUILD_ID (unique build ID bitstring)
+# GNU-STRIPPED-NEXT:    Build ID: 4fcb712aa6387724a9f465a32cd8c14b
----------------
Could you make a follow-up commit to share this with the above GNU case, please? This could be achieved with something like:

```
# RUN: ... | FileCheck %s --check-prefixes=GNU,UNSTRIPPED -DOFFSET=0x00000238
# RUN: ... | FileCheck %s --check-prefix=GNU --implicit-check-not={{.}} -DOFFSET=0x00000040

#      GNU:Displaying notes found at file offset [[OFFSET]] with length 0x00000020:
# GNU-NEXT:  Owner                Data size   Description
# GNU-NEXT:  GNU                  0x00000010  NT_GNU_ABI_TAG (ABI version tag)
# GNU-NEXT:    OS: Linux, ABI: 2.6.32

#      UNSTRIPPED:Displaying notes found at file offset 0x00000258 with length 0x00000020:
# UNSTRIPPED-NEXT:  Owner                Data size   Description
...
```

The same sort of thing should work with the LLVM output. By doing this, you avoid the duplicate contents, and illustrate that the part covered by the program header should be identical.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D66358





More information about the llvm-commits mailing list