Date: Mon, 3 Jul 2017 04:21:17 -0700 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: head -r320570 (e.g.): ld crashes on powerpc64. . . (this was during port builds, I got about 65 of them) Message-ID: <39759CC6-03A4-4041-8B2C-93E030E733AB@dsl-only.net>
next in thread | raw e-mail | index | archive | help
Using one of the examples for illustration of what is
common to each that I've looked at:
Core was generated by `/usr/bin/ld --eh-frame-hdr -Bstatic -o conftest =
/usr/lib/crt1.o /usr/lib/crti.o'.
Program terminated with signal 11, Segmentation fault.
#0 0x000000001002dc78 in .text ()
(gdb) bt
#0 0x000000001002dc78 in .text ()
#1 0x000000001000101c in ppc_before_allocation () at =
eelf64ppc_fbsd.c:204
#2 0x0000000010009a2c in ldemul_before_allocation () at =
/usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldemul.c:=
78
#3 0x0000000010017844 in lang_process () at =
/usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldlang.c:=
5785
#4 0x00000000100219b0 in main (argc=3D0, argv=3D<value optimized out>) =
at =
/usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmain.c:=
459
#5 0x000000001000049c in .text ()
#1 source around eelf64ppc_fbsd.c:204 being:
199 TLS segment layout so that certain optimizations =
can be done. */
200 expld.phase =3D lang_mark_phase_enum;
201 expld.dataseg.phase =3D exp_dataseg_none;
202 one_lang_size_sections_pass (NULL, TRUE);
203=09
204 if (!ppc64_elf_tls_optimize (output_bfd, &link_info))
205 einfo ("%X%P: TLS problem %E\n");
206=09
207 /* We must not cache anything from the preliminary =
sizing. */
208 lang_reset_memory_regions ();
where lines 202/204 are:
0x0000000010000ff4 <ppc_before_allocation+236>: li r3,0
0x0000000010000ff8 <ppc_before_allocation+240>: li r4,1
0x0000000010000ffc <ppc_before_allocation+244>: bl 0x10013fbc =
<one_lang_size_sections_pass>
0x0000000010001000 <ppc_before_allocation+248>: nop
0x0000000010001004 <ppc_before_allocation+252>: nop
0x0000000010001008 <ppc_before_allocation+256>: addis r4,r2,1
0x000000001000100c <ppc_before_allocation+260>: addi r3,r2,-11840
0x0000000010001010 <ppc_before_allocation+264>: addi r4,r4,-5320
0x0000000010001014 <ppc_before_allocation+268>: ld r3,0(r3)
0x0000000010001018 <ppc_before_allocation+272>: bl 0x1002d90c =
<.text+186188>
0x000000001000101c <ppc_before_allocation+276>: nop
And that last bl starts out at:
0x1002d90c <.text+186188>: mflr r0
0x1002d910 <.text+186192>: mfcr r12
0x1002d914 <.text+186196>: std r31,-8(r1)
0x1002d918 <.text+186200>: std r0,16(r1)
0x1002d91c <.text+186204>: stw r12,8(r1)
0x1002d920 <.text+186208>: stdu r1,-384(r1)
0x1002d924 <.text+186212>: mr r31,r1
0x1002d928 <.text+186216>: nop
0x1002d92c <.text+186220>: std r30,368(r31)
0x1002d930 <.text+186224>: addi r30,r2,11904
0x1002d934 <.text+186228>: std r28,352(r31)
0x1002d938 <.text+186232>: std r14,240(r31)
0x1002d93c <.text+186236>: std r15,248(r31)
0x1002d940 <.text+186240>: std r16,256(r31)
0x1002d944 <.text+186244>: std r17,264(r31)
0x1002d948 <.text+186248>: std r18,272(r31)
0x1002d94c <.text+186252>: std r19,280(r31)
0x1002d950 <.text+186256>: std r20,288(r31)
0x1002d954 <.text+186260>: std r21,296(r31)
0x1002d958 <.text+186264>: std r22,304(r31)
0x1002d95c <.text+186268>: std r23,312(r31)
0x1002d960 <.text+186272>: std r24,320(r31)
0x1002d964 <.text+186276>: std r25,328(r31)
0x1002d968 <.text+186280>: std r26,336(r31)
0x1002d96c <.text+186284>: std r27,344(r31)
0x1002d970 <.text+186288>: std r29,360(r31)
0x1002d974 <.text+186292>: mr r28,r4
0x1002d978 <.text+186296>: ld r3,0(r30)
. . .
(r3 is replaced before its value is used.)
Around 0x000000001002dc78 (for #0) is:
0x1002dc0c <.text+186956>: b 0x1002de6c <.text+187564>
0x1002dc10 <.text+186960>: cmplwi r4,0
0x1002dc14 <.text+186964>: beq- 0x1002e0a0 <.text+188128>
0x1002dc18 <.text+186968>: li r3,20
0x1002dc1c <.text+186972>: li r22,4
0x1002dc20 <.text+186976>: li r30,0
0x1002dc24 <.text+186980>: li r6,0
0x1002dc28 <.text+186984>: b 0x1002dc64 <.text+187044>
0x1002dc2c <.text+186988>: li r6,1
0x1002dc30 <.text+186992>: cmplwi r4,0
0x1002dc34 <.text+186996>: li r30,80
0x1002dc38 <.text+187000>: beq- 0x1002dc40 <.text+187008>
0x1002dc3c <.text+187004>: li r30,0
0x1002dc40 <.text+187008>: li r3,17
0x1002dc44 <.text+187012>: li r22,1
0x1002dc48 <.text+187016>: b 0x1002dc64 <.text+187044>
0x1002dc4c <.text+187020>: li r6,1
0x1002dc50 <.text+187024>: cmplwi r5,0
0x1002dc54 <.text+187028>: beq- 0x1002e0a0 <.text+188128>
0x1002dc58 <.text+187032>: li r3,18
0x1002dc5c <.text+187036>: li r22,2
0x1002dc60 <.text+187040>: li r30,0
0x1002dc64 <.text+187044>: cmpwi r6,0
0x1002dc68 <.text+187048>: crnot 4*cr5+lt,eq
0x1002dc6c <.text+187052>: beq- cr2,0x1002dd14 <.text+187220>
0x1002dc70 <.text+187056>: bge- cr5,0x1002dcf4 <.text+187188>
0x1002dc74 <.text+187060>: ld r4,544(r15)
0x1002dc78 <.text+187064>: ld r4,80(r4)
0x1002dc7c <.text+187068>: cmpldi r4,0
0x1002dc80 <.text+187072>: bne- 0x1002dc94 <.text+187092>
0x1002dc84 <.text+187076>: b 0x1002dcac <.text+187116>
info reg show r4 as 0x0.
I expect that the failure is during the
tls_get_addr dereference in
htab->tls_get_addr->elf.plt.plist in the
first loop below: htab->tls_get_addr is
NULL as far as I can tell. . .
In ppc_before_allocation :
if (expecting_tls_get_addr)
{
struct plt_entry *ent;
for (ent =3D htab->tls_get_addr->elf.plt.plist;
ent !=3D NULL;
ent =3D ent->next)
if (ent->addend =3D=3D 0)
{
if (ent->plt.refcount > 0)
{
ent->plt.refcount -=3D 1;
expecting_tls_get_addr =3D 0;
}
break;
}
}
if (expecting_tls_get_addr)
{
struct plt_entry *ent;
for (ent =3D htab->tls_get_addr_fd->elf.plt.plist;
ent !=3D NULL;
ent =3D ent->next)
if (ent->addend =3D=3D 0)
{
if (ent->plt.refcount > 0)
ent->plt.refcount -=3D 1;
break;
}
}
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39759CC6-03A4-4041-8B2C-93E030E733AB>