[Toybox] [PATCH] readelf: Fix the section flags handling.

[Rob Landley]

On 11/30/23 13:18, enh wrote:
>> Design-wise calling for an exact match for a very large block of english text is
>> brittle. If spacing changes, the test breaks.
> 
> we already have the `NOSPACE=1` "ignore whitespace differences"
> functionality in the readelf tests.
> 
> what's the actual difference in the failure you're seeing?

Version skew in the host readelf:

echo -ne '' | readelf -SW
/home/landley/toybox/toybox/tests/files/elf/ndk-elf-note-shflags | head -32
--- expected	2023-11-30 13:44:43.199143754 -0600
+++ actual	2023-11-30 13:44:43.203143754 -0600
@@ -1,7 +1,7 @@
 There are 28 section headers, starting at offset 0xc74:

 Section Headers:
-  [Nr] Name              Type            Address  Off    Size   ES Flg Lk Inf Al
+  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
   [ 0]                   NULL            00000000 000000 000000 00      0   0  0
   [ 1] .interp           PROGBITS        000001b4 0001b4 000013 00   A  0   0  1
   [ 2] .note.android.ident NOTE            000001c8 0001c8 000018 00   A  0   0  4
@@ -11,8 +11,8 @@
   [ 6] .gnu.version_r    VERNEED         0000026c 00026c 000020 00   A  8   1  4
   [ 7] .gnu.hash         GNU_HASH        0000028c 00028c 000018 00   A  4   0  4
   [ 8] .dynstr           STRTAB          000002a4 0002a4 000064 00   A  0   0  1
-  [ 9] .rel.dyn          ANDROID_REL     00000308 000308 00000d 01   A  4   0  4
-  [10] .relr.dyn         RELR            00000318 000318 00000c 04   A  0   0  4
+  [ 9] .rel.dyn          LOOS+0x1        00000308 000308 00000d 01   A  4   0  4
+  [10] .relr.dyn         00000013: <unknown> 00000318 000318 00000c 04   A  0
0  4
   [11] .ARM.exidx        ARM_EXIDX       00000324 000324 000028 00  AL 14   0  4
   [12] .rel.plt          REL             0000034c 00034c 000020 08  AI  4  19  4
   [13] .rodata           PROGBITS        0000036c 00036c 000015 01 AMS  0   0  1
@@ -24,7 +24,7 @@
   [19] .got.plt          PROGBITS        000026a0 0006a0 00001c 00  WA  0   0  4
   [20] .data             PROGBITS        000036bc 0006bc 00000c 00  WA  0   0  4
   [21] .comment          PROGBITS        00000000 0006c8 0000cc 01  MS  0   0  1
-  [22] .ARM.attributes   ATTRIBUTES      00000000 000794 000042 00      0   0  1
+  [22] .ARM.attributes   ARM_ATTRIBUTES  00000000 000794 000042 00      0   0  1
   [23] .debug_frame      PROGBITS        00000000 0007d8 00007a 00   C  0   0  4
   [24] .symtab           SYMTAB          00000000 000854 000220 10     26  27  4
   [25] .shstrtab         STRTAB          00000000 000a74 00010e 00      0   0  1
make: *** [.singlemake:809: test_readelf] Error 1


(I still haven't switched from devuan bridezilla to devuan deadlock.)

>> If somebody rephrases "Number of
>> section headers:" the test breaks. If the output entries are reordered
>> (including adding more entries in the middle) the test breaks. Even if we fiddle
>> to match debian's output, version skew will break us in a year or two...
> 
> _maybe_ but there are a lot of scripts out there to help keep them
> (and us) honest. that's why i have tried to match the binutils output,
> even when it's not great.

Binutils output changing over time is the majority of the version skew I'm
worried about. Scripts that parse that output have to be brittle by nature.

(This is why Mike Gancarz' book "the unix philosophy" talked about unix tool
output being made to be easily parseable by programs rather than by humans.
Alas, readelf is from gnu, not from unix, which is why it sucks at this. The nm
tool has better unix design, which is why bloat-o-meter and make bloatcheck is
built on top of it. Specifically the --size-sort output which has constant
fields rather than this "the first word is missing half the time and the
indentation easily lets a human know but is a pain for a script to deal with
unless it wants to hardwire in column starting positions and break as soon as a
field width changes" of the default output.)

Rob