[PATCH] D71333: [llvm-readobj][test] - Add a test for testing regular section flags and cleanup flags testing.
George Rimar via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Dec 12 02:46:12 PST 2019
grimar added inline comments.
================
Comment at: llvm/test/tools/llvm-readobj/ELF/section-arch-flags.test:33-34
+# MIPS-LLVM: Flags [ (0xFF000000)
+# MIPS-LLVM-NEXT: SHF_EXCLUDE (0x80000000)
+# MIPS-LLVM-NEXT: SHF_MASKPROC (0xF0000000)
+# MIPS-LLVM-NEXT: SHF_MIPS_ADDR (0x40000000)
----------------
jhenderson wrote:
> Where have these two flags come from?
>
> SHF_MASKPROC in particular is concerning, since it's a range delimiter, not an actual value... That's probably a bug.
The code related is:
https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-readobj/ELFDumper.cpp#L1131
https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-readobj/ELFDumper.cpp#L5358
I.e. for LLVM style it pushes all the SHF_*, including masks to array and prints all of them.
GNU style is a bit different, it drops the bits during proccessing:
https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-readobj/ELFDumper.cpp#L1176
But note that 'SHF_EXCLUDE' has the same value as 'SHF_MIPS_STRING`:
```
// This section is excluded from the final executable or shared library.
SHF_EXCLUDE = 0x80000000U,
// Section data is string data by default.
SHF_MIPS_STRING = 0x80000000,
```
So we probably should not attemp to drop them in LLVM style. That is why
we print both SHF_EXCLUDE and SHF_MIPS_STRING flags.
The situation with the `SHF_MASKPROC` is similar. It has value of 0xf0000000,
and the value of `SHF_MIPS_GPREL + SHF_MIPS_MERGE + SHF_MIPS_ADDR + SHF_MIPS_STRING`
also gives us 0xf0000000. Though in this `SHF_MASKPROC` it is a mask value and I agree
that we should not print `SHF_MASKPROC` (and `SHF_MASKOS`).
So I think we should add a test showing that them are not printed, for example
when the flag value is 0xffffffff. For that we need a yam2obj change discussed to
be done first.
I've added a FIXME comment here and do that in the follow-up too.
(If you think we should do a change for yaml2obj first, please say.)
FTR, I've also tried to use both mips-linux-gnu-readelf and regular x86 readelf and got:
```
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .mips PROGBITS 00000000 000034 000000 00 Dop 0 0 0
...
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
p (processor specific)
```
I.e. it prints "D" instead of "E", but doesn't give an explanation about what it is.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D71333/new/
https://reviews.llvm.org/D71333
More information about the llvm-commits
mailing list