[PATCH] D58677: [llvm-readobj]Add additional testing for various ELF features

James Henderson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 27 04:06:30 PST 2019


jhenderson marked 5 inline comments as done.
jhenderson added inline comments.


================
Comment at: test/tools/llvm-readobj/elf-dynamic-malformed.test:92
+      - Tag:   DT_NEEDED
+        Value: 1
+      - Tag:   DT_NULL
----------------
grimar wrote:
> Do I correctly understand that issue here is that DT_NEEDED has a value 0x1, which
> is an offset in a .dynstr, and the issue is that DT_STRSZ says that .dynstr has a total size of 1
> (and so offset 0x1 is past the end of the section)?
> 
> If so, it is not really obvious perhaps, I would suggest extending the comment for this sub-test.
Yes, that's correct. I'll improve it.


================
Comment at: test/tools/llvm-readobj/elf-dynamic-tags.test:213
+      - Tag:   DT_FLAGS
+        Value: 0xaabbccddeeff9900
+      - Tag:   DT_PREINIT_ARRAY
----------------
MaskRay wrote:
> 0x1f to enumerate all DF_* flags?
I'll go the whole hog and do 0xffffffffffffffff, to enumerate all flags current and future.


================
Comment at: test/tools/llvm-readobj/elf-dynamic-tags.test:251
+      - Tag:   DT_FLAGS_1
+        Value: 0x87654321
+      - Tag:   DT_VERSYM
----------------
MaskRay wrote:
> Use 0x03ffffff to enumerate all DF_1_* flags?
Ditto.


================
Comment at: test/tools/llvm-readobj/elf-dynamic-tags.test:275
+      - Tag:   0x7ffffffe
+        Value: 0x8888777766665555
+      - Tag:   DT_NULL
----------------
grimar wrote:
> Could you explain the logic of numeric tags for me?
> 
> I see you're testing LOPROC and (HIPROC-1) it seems:
> 
> > DYNAMIC_TAG_MARKER(LOOS, 0x60000000)   // Start of environment specific tags.
> > DYNAMIC_TAG_MARKER(HIOS, 0x6FFFFFFF)   // End of environment specific tags.
> > DYNAMIC_TAG_MARKER(LOPROC, 0x70000000) // Start of processor specific tags.
> > DYNAMIC_TAG_MARKER(HIPROC, 0x7FFFFFFF) // End of processor specific tags.
> 
> But what is 0x6000000D and 0x6ffff000 then?
I can't remember my own logic now!

I'm interested in other reserved values effectively, that don't have a known meaning in LLVM, but looking at the known values, I don't see any reason to not use 0x60000000. Note that 0x6FFFFFFF is DT_VERNEEDNUM, so I can't use that. The highest I can use is 0x6FFFFFF8, I believe. I could also test a mid-range value too, if that's desirable?

By the way, I'm using 0x7ffffffe, because 0x7fffffff is DT_FILTER.


================
Comment at: test/tools/llvm-readobj/elf-malformed-PT_DYNAMIC.test:16-17
+# RUN: cp %t.stripped %t.truncated1
+# RUN: %python -c "with open(r'%t.truncated', 'r+') as f: f.truncate(0x1001)"
+# RUN: not llvm-readobj %t.truncated --dynamic-table 2>&1 | FileCheck %s
+
----------------
Higuoxing wrote:
> Here should be
> ```
> # RUN: %python -c "with open(r'%t.truncated1', 'r+') as f: f.truncate(0x1001)"
>                                            ^
> # RUN: not llvm-readobj %t.truncated1 --dynamic-table 2>&1 | FileCheck %s
>                                     ^
> ```
> right?
Oops, thanks. I'll fix that. I renamed the file, so there must be one still in my test output directory of the old name.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D58677





More information about the llvm-commits mailing list