On Thu, Nov 30, 2023 at 11:49 AM Rob Landley <r...@landley.net> wrote: > > 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
okay, that looks like the kind of nonsense you're complaining about :-( but why doesn't the existing test on line 34 fail this too? (or do you really have a binutils older than any i've used while working on toybox readelf?) > [ 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 (yeah, that's probably just a binutils too old to recognize RELR.) > 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 this one's my fault from a recent change --- i left it alone because _really_ when you're decoding stuff in that space you need to _also_ check the architecture, and we don't have anything like that atm, and it didn't seem worth it yet. > [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.) that might be the difference here, yes. the other differences you can make go away by just not using an arm32 ELF file (or possibly even just "not built by the NDK"). (the ARM_ATTRIBUTES one we might just want to change and admit that our decoding of machine-specific SHT_ values is a bit dodgy.) > >> 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. yeah, and while two . > (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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
