[PATCH] D78805: [llvm-readobj][test] - Stop using binaries in gnu-phdrs.test, split and refine it.

James Henderson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 29 01:02:17 PDT 2020


jhenderson added inline comments.


================
Comment at: llvm/test/tools/llvm-readobj/ELF/gnu-phdrs.test:290-293
+## Check that --section-mapping=false --program-headers produces just program headers.
+## See more tests for interactions with '--section-mapping' in gnu-section-mapping.test.
+# RUN: llvm-readelf --section-mapping=false --program-headers %t64.elf \
+# RUN:   | FileCheck %s --check-prefix=ELF64 --implicit-check-not="Section to Segment mapping:"
----------------
I'd be inclined to move this case into the section mapping test, and then simplify it down to show that program headers are emitted (but no need to check the full output). That way, the "Section to Segment mapping:" implicit-check-not is going to be closer to the true case, and less likely to get broken at some future point.


================
Comment at: llvm/test/tools/llvm-readobj/ELF/gnu-section-mapping.test:11-12
+# MAPPING-NEXT:  Segment Sections...
+# MAPPING-NEXT:   00     .foo.begin .foo.end {{$}}
+# MAPPING-NEXT:   01     .bar.begin .bar.end {{$}}
+# MAPPING-NEXT:   None   .strtab .shstrtab {{$}}
----------------
I suspect we might want a few more test-cases here. Some examples off the top of my head:

* Sections in segments which are themselves inside other segments.
* TLS segment + trailing .tbss
* Other nobits sections (both in middle and at end of segments).
* Empty sections at start/middle/ends of segments
* Sections that only partly overlap a segment (i.e. their start is before the start of a segment and/or their end is after the end of a segment).
* Sections in a segment by address but not offset.
* Sections in a segment by offset but not address.

There may well be others that I haven't thought of.


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

https://reviews.llvm.org/D78805





More information about the llvm-commits mailing list