[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