Ben Hutchings dixit:
>7.2. This introduced regressions for shared-library executables for
I did notice the following:
amd64:
/lib/klibc-YUkGbOClhnaZRUUd4cUed0X2XZI.so: file format elf64-x86-64
/lib/klibc-YUkGbOClhnaZRUUd4cUed0X2XZI.so
architecture: i386:x86-64, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x0000000000201034
Program Header:
LOAD off 0x0000000000000000 vaddr 0x0000000000200000 paddr
0x0000000000200000 align 2**12
filesz 0x00000000000001b4 memsz 0x00000000000001b4 flags r--
LOAD off 0x0000000000001000 vaddr 0x0000000000201000 paddr
0x0000000000201000 align 2**12
filesz 0x000000000000cf07 memsz 0x000000000000cf07 flags r-x
LOAD off 0x000000000000e000 vaddr 0x000000000020e000 paddr
0x000000000020e000 align 2**12
filesz 0x0000000000003f6f memsz 0x0000000000003f6f flags r--
LOAD off 0x0000000000012000 vaddr 0x0000000000212000 paddr
0x0000000000212000 align 2**12
filesz 0x0000000000000140 memsz 0x0000000000004438 flags rw-
NOTE off 0x0000000000000190 vaddr 0x0000000000200190 paddr
0x0000000000200190 align 2**2
filesz 0x0000000000000024 memsz 0x0000000000000024 flags r--
STACK off 0x0000000000000000 vaddr 0x0000000000000000 paddr
0x0000000000000000 align 2**4
filesz 0x0000000000000000 memsz 0x0000000000000000 flags rwx
Sections:
Idx Name Size VMA LMA File off Algn
0 .note.gnu.build-id 00000024 0000000000200190 0000000000200190 00000190
2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .text 0000cf07 0000000000201000 0000000000201000 00001000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
[…]
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz
Flg Align
LOAD 0x000000 0x0000000000200000 0x0000000000200000 0x0001b4
0x0001b4 R 0x1000
LOAD 0x001000 0x0000000000201000 0x0000000000201000 0x00cf07
0x00cf07 R E 0x1000
LOAD 0x00e000 0x000000000020e000 0x000000000020e000 0x003f6f
0x003f6f R 0x1000
LOAD 0x012000 0x0000000000212000 0x0000000000212000 0x000140
0x004438 RW 0x1000
NOTE 0x000190 0x0000000000200190 0x0000000000200190 0x000024
0x000024 R 0x4
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000
0x000000 RWE 0x10
Section to Segment mapping:
Segment Sections...
00 .note.gnu.build-id
01 .text
02 .rodata
03 .data .bss
04 .note.gnu.build-id
armhf:
/lib/klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so: file format elf32-littlearm
/lib/klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so
architecture: armv7, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x003800f9
Program Header:
LOAD off 0x00000000 vaddr 0x00380000 paddr 0x00380000 align 2**12
filesz 0x0000cecf memsz 0x0000cecf flags r-x
LOAD off 0x0000d000 vaddr 0x0038d000 paddr 0x0038d000 align 2**12
filesz 0x000000b8 memsz 0x00002254 flags rw-
NOTE off 0x000000b4 vaddr 0x003800b4 paddr 0x003800b4 align 2**2
filesz 0x00000024 memsz 0x00000024 flags r--
STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**4
filesz 0x00000000 memsz 0x00000000 flags rw-
private flags = 5000400: [Version5 EABI] [hard-float ABI]
Sections:
Idx Name Size VMA LMA File off Algn
0 .note.gnu.build-id 00000024 003800b4 003800b4 000000b4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .text 00009974 003800d8 003800d8 000000d8 2**3
CONTENTS, ALLOC, LOAD, READONLY, CODE
[…]
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00380000 0x00380000 0x0cecf 0x0cecf R E 0x1000
LOAD 0x00d000 0x0038d000 0x0038d000 0x000b8 0x02254 RW 0x1000
NOTE 0x0000b4 0x003800b4 0x003800b4 0x00024 0x00024 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10
Section to Segment mapping:
Segment Sections...
00 .note.gnu.build-id .text .rodata
01 .data .bss
02 .note.gnu.build-id
Specifically, what I noted is that, on amd64, the .text section
inside the text segment, which here isn’t shared with the buildid
section, has a page align increment from .note.gnu.build-id but
the armhf one doesn’t.
So I added -Ttext 0x381000 to the link command, to get…
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0000997c 00381000 00381000 00001000 2**3
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .note.gnu.build-id 00000024 003800b4 003800b4 000000b4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
[…]
… but the segfault persists, so maybe that’s not it, or that’s
not yet enough and we have to use a linker script to put the
buildid section inside its own segment like it does on amd64.
The failing offset is 0x3800F8, which is a couple of bytes into
.text, after all.
But /proc/27269/maps for the qemu process (with a user memory
base of 0x40D94000 so the failing address is 0x411140F8, this
isn’t reflected…
40da6000-80d94000 ---p 00000000 00:00 0
… in contrast to lower user memory, which has…
40da4000-40da5000 r--p 00000000 fd:00 2234167
/home/tglase/fstype
40da5000-40da6000 rw-p 00000000 fd:00 2234167
/home/tglase/fstype
… the fstype binary mapped. So maybe qemu fails totally to load
and/or map the interpreter 🙀
I think pretty much *any* dynamically-linked klibc binary should
fail with that, right now, independent of what features it uses
or something, as the code isn’t even reached.
And, indeed, the combination of klibc-sKNr1Fw-Rh9G1FYpGCXRnrwmP2A.so
and fstype from 2.0.4-2 (jessie) also fails, so you have something
that can reliably be used in bisect tests I think.
Good luck,
//mirabilos
--
<ch> you introduced a merge commit │<mika> % g rebase -i HEAD^^
<mika> sorry, no idea and rebasing just fscked │<mika> Segmentation
<ch> should have cloned into a clean repo │ fault (core dumped)
<ch> if I rebase that now, it's really ugh │<mika:#grml> wuahhhhhh
