Am 21.02.2019 um 10:36 schrieb Konstantin Belousov:
…

ELF Header:
    Magic:   7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00
    Class:                             ELF64
    Data:                              2's complement, little endian
    Version:                           1 (current)
    OS/ABI:                            FreeBSD
    ABI Version:                       0
    Type:                              DYN (Shared object file)
    Machine:                           Advanced Micro Devices x86-64
    Version:                           0x1
    Entry point address:               0x116000
    Start of program headers:          64 (bytes into file)
    Start of section headers:          3090864 (bytes into file)
    Flags:                             0
    Size of this header:               64 (bytes)
    Size of program headers:           56 (bytes)
    Number of program headers:         8
    Size of section headers:           64 (bytes)
    Number of section headers:         29
    Section header string table index: 28

Elf file type is DYN (Shared object file)
Entry point 0x116000
There are 8 program headers, starting at offset 64

Program Headers:
    Type           Offset             VirtAddr           PhysAddr
                   FileSiz            MemSiz              Flg    Align
    PHDR           0x0000000000000040 0x0000000000000040 0x0000000000000040
                   0x00000000000001c0 0x00000000000001c0  R      0x8
    LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                   0x0000000000115a7c 0x0000000000115a7c  R      0x1000
    LOAD           0x0000000000116000 0x0000000000116000 0x0000000000116000
                   0x00000000001acb20 0x00000000001acb20  R E    0x1000
    LOAD           0x00000000002c3000 0x00000000002c3000 0x00000000002c3000
                   0x000000000002f790 0x00000000000325e0  RW     0x1000
    DYNAMIC        0x00000000002f1a80 0x00000000002f1a80 0x00000000002f1a80
                   0x0000000000000190 0x0000000000000190  RW     0x8
    GNU_RELRO      0x00000000002c9000 0x00000000002c9000 0x00000000002c9000
                   0x0000000000029790 0x0000000000029790  R      0x1
    GNU_EH_FRAME   0x00000000000d0050 0x00000000000d0050 0x00000000000d0050
                   0x000000000000bc74 0x000000000000bc74  R      0x4
    GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                   0x0000000000000000 0x0000000000000000  RW     0

   Section to Segment mapping:
    Segment Sections...
     00
     01     (null) (null) (null) (null) (null) (null) (null) (null)
(null) (null) (null) (null) (null) (null) (null) (null) (null) (null)
(null) (null) (null) (null) (null) (null) (null) (null) (null) (null)
     02
     03
     04
     05
     06
     07     (null) (null) (null) (null) (null) (null) (null) (null)
(null) (null) (null) (null) (null) (null) (null) (null) (null) (null)
(null) (null) (null) (null) (null) (null) (null) (null) (null) (null)
There are 29 section headers, starting at offset 0x2f29b0:

The object is clearly corrupted.

Thanks to your hint to readelf, I found out that it gets corrupted during dump(8) (or resotore, not yet analyzed).
The obj tree contains the good version, the dump archive not.
The dump archive is used as source for the ISO, hence the described errors.
Now I have to dig in 10 years old deployment scripts to track down and reproduce the corruption. No explanation so far, but for sure no rtld-elf problem :-) And also not a problem in the FreeBSD make chain, building stable/12 on stable/11 works as intended and doesn't produce the mutilated libcrypto.so.111!

Thanks,

-harry
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"

Reply via email to