[Bug 206123] devel/powerpc64-gcc (as of -r405762 and before): powerpc64 lib32 use fails because of crtbeginS.o powerpc64-gcc produces
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Mon Jan 11 03:25:08 UTC 2016
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206123
Bug ID: 206123
Summary: devel/powerpc64-gcc (as of -r405762 and before):
powerpc64 lib32 use fails because of crtbeginS.o
powerpc64-gcc produces
Product: Ports & Packages
Version: Latest
Hardware: ppc
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: Individual Port(s)
Assignee: bapt at FreeBSD.org
Reporter: markmi at dsl-only.net
Assignee: bapt at FreeBSD.org
Flags: maintainer-feedback?(bapt at FreeBSD.org)
powerpc64 context: devel/powerpc64-gcc used for buildworld produces a -m32
-mcpu=powerpc crtbeginS.o (WITH_LIB32= for powerpc64 or for
TARGET_ARCH=powerpc) that is not suitable. This leads to _init in
/usr/lib32/libc.so.7 crashing, preventing lib32's use.
(If I avoid use of lib32 I can use powerpc64-gcc to build and install kernel
and world, including WITH_BOOT= . WITH_LIB32= does build and install --it just
does not work.)
The lib32/crtbeginS.o ends up with .init code that looks like:
# /usr/local/powerpc64-freebsd/bin/objdump -d /usr/lib32/crtbeginS.o | tail -20
178: 7d 61 5b 78 mr r1,r11
17c: 4e 80 00 20 blr
Disassembly of section .fini:
00000000 <.fini>:
0: 48 00 00 01 bl 0 <.fini>
Disassembly of section .init:
00000000 <.init>:
0: 80 7e 00 00 lwz r3,0(r30)
4: 81 23 00 00 lwz r9,0(r3)
8: 2f 89 00 00 cmpwi cr7,r9,0
c: 41 9e 00 18 beq cr7,24 <__do_global_dtors_aux+0x24>
10: 81 3e 00 00 lwz r9,0(r30)
14: 2f 89 00 00 cmpwi cr7,r9,0
18: 41 9e 00 0c beq cr7,24 <__do_global_dtors_aux+0x24>
1c: 7d 29 03 a6 mtctr r9
20: 4e 80 04 21 bctrl
which depends on r30's preexisting value (and the offset ends up adjusted from
zero when put to use in /usr/lib32/libc.so.7).
For comparison/contrast: From a buildworld that uses gcc4.2.1's toolchain
(src.conf empty):
# /usr/local/powerpc64-freebsd/bin/objdump -d
/usr/obj/lib32/usr/src/gnu/lib/csu/crtbeginS.o | tail
Disassembly of section .fini:
00000000 <.fini>:
0: 48 00 00 01 bl 0 <.fini>
Disassembly of section .init:
00000000 <.init>:
0: 48 00 00 01 bl 0 <.init>
Back to how the powerpc64-gcc's produced crtbeginS.o behaves in use:
For compiling with -m32 via powerpc64-gcc lib32/libc.so.7 dies in its _init:
# more main.c
int main(void)
{
return 0;
}
# /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc --version
powerpc64-portbld-freebsd11.0-gcc (FreeBSD Ports Collection for powerpc64)
5.2.0
. . .
# /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -m32 -mcpu=powerpc main.c
# file a.out
a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (FreeBSD),
dynamically linked, interpreter /libexec/ld-elf.so.1, FreeBSD-style, for
FreeBSD 11.0 (1100093), not stripped
# /usr/local/bin/gdb a.out
GNU gdb (GDB) 7.10 [GDB v7.10 for FreeBSD]
. . .
Reading symbols from a.out...(no debugging symbols found)...done.
(gdb) run
Starting program: /root/c_tests/a.out
warning: `/libexec/ld-elf.so.1': Shared library architecture powerpc:common64
is not compatible with target architecture powerpc:common.
warning: `/libexec/ld-elf.so.1': Shared library architecture powerpc:common64
is not compatible with target architecture powerpc:common.
Program received signal SIGSEGV, Segmentation fault.
0x41867ebc in _init () from /usr/lib32/libc.so.7
(gdb) x/20i 0x41867ea0
0x41867ea0: .long 0xc3b15
0x41867ea4: .long 0x0
0x41867ea8 <_init>: stwu r1,-16(r1)
0x41867eac <_init+4>: mflr r0
0x41867eb0 <_init+8>: stw r31,12(r1)
0x41867eb4 <_init+12>: stw r0,20(r1)
0x41867eb8 <_init+16>: mr r31,r1
=> 0x41867ebc <_init+20>: lwz r3,-11432(r30)
0x41867ec0 <_init+24>: lwz r9,0(r3)
0x41867ec4 <_init+28>: cmpwi cr7,r9,0
0x41867ec8 <_init+32>: beq cr7,0x41867ee0 <_init+56>
0x41867ecc <_init+36>: lwz r9,-856(r30)
0x41867ed0 <_init+40>: cmpwi cr7,r9,0
0x41867ed4 <_init+44>: beq cr7,0x41867ee0 <_init+56>
0x41867ed8 <_init+48>: mtctr r9
0x41867edc <_init+52>: bctrl
0x41867ee0 <_init+56>: lwz r29,-1140(r30)
0x41867ee4 <_init+60>: lwzu r9,-4(r29)
0x41867ee8 <_init+64>: cmpwi cr7,r9,-1
0x41867eec <_init+68>: beq cr7,0x41867f04 <_init+92>
(gdb) info registers
. . .
r30 0x4183bb8c 1099152268
r31 0xffffd730 4294956848
pc 0x41867ebc 0x41867ebc <_init+20>
msr <unavailable>
cr 0x28000482 671089794
lr 0x41814d9c 0x41814d9c <objlist_call_init+296>
. . .
(gdb) x/150i objlist_call_init
0x41814c74 <objlist_call_init>: stwu r1,-64(r1)
0x41814c78 <objlist_call_init+4>: mflr r0
0x41814c7c <objlist_call_init+8>: bl 0x4183bb88
0x41814c80 <objlist_call_init+12>: li r8,0
0x41814c84 <objlist_call_init+16>: stw r30,56(r1)
0x41814c88 <objlist_call_init+20>: mflr r30
. . .
0x41814d88 <objlist_call_init+276>: bl 0x418131b0 <ld_utrace_log>
0x41814d8c <objlist_call_init+280>: lwz r9,4(r28)
0x41814d90 <objlist_call_init+284>: lwz r5,256(r9)
0x41814d94 <objlist_call_init+288>: mtctr r5
0x41814d98 <objlist_call_init+292>: bctrl
0x41814d9c <objlist_call_init+296>: lwz r10,4(r28)
0x41814da0 <objlist_call_init+300>: lwz r29,268(r10)
. . .
(gdb) info registers
. . .
r30 0x4183bb8c 1099152268
. . .
(gdb) x/20i 0x4183bb8c - 0x10
0x4183bb7c: bso 0x4183778c
0x4183bb80: bso 0x41837788
0x4183bb84: bso 0x4183773c
0x4183bb88: blrl
0x4183bb8c <_SDA_BASE_>: .long 0x2b428
0x4183bb90 <_SDA_BASE_+4>: .long 0x0
0x4183bb94 <_SDA_BASE_+8>: .long 0x0
0x4183bb98 <_thread_autoinit_dummy_decl>: .long 0x1
0x4183bb9c <ld_env_prefix>: beq 0x41835b80
0x4183bba0 <ld_standard_library_path>: beq 0x41835b8c
0x4183bba4 <ld_path_rtld>: beq 0x41835ba4
0x4183bba8 <ld_path_libmap_conf>: beq 0x41835bc0
0x4183bbac <ld_elf_hints_default>: beq 0x41835bd8
0x4183bbb0 <tls_max_index>: .long 0x2
0x4183bbb4 <tls_dtv_generation>: .long 0x2
0x4183bbb8 <rtld_phdr_lock>: bso 0x4183822c
0x4183bbbc <rtld_libc_lock>: bso 0x41838228
0x4183bbc0 <rtld_bind_lock>: bso 0x41838224
0x4183bbc4 <realloc_srchlen>: .long 0x4
0x4183bbc8 <lmp_head>: beq 0x41838be8
(gdb) x/i 0x4183bb8c - 11432
0x41838ee4: Cannot access memory at address 0x41838ee4
So the "lwz r3,-11432(r30)" ends up referencing <_SDA_BASE_-11432>, which is
not accessible.
So far I have not managed to track down why the r30 based .init code shows up
--or even what call standard(s) use r30 in a way that would appear to match.
But the code's behavior seems to be just wrong for the FreeBSD powerpc context.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-ports-bugs
mailing list