Date: Tue, 22 Jan 2019 22:53:55 -0800 From: Mark Millard <marklmi@yahoo.com> To: John Baldwin <jhb@freebsd.org> Cc: "freebsd-ppc@freebsd.org" <freebsd-ppc@FreeBSD.org> Subject: Re: GDB TLS testing [actually running some tests finally but these tests fail] Message-ID: <B07EC3F9-6C08-4B5D-89D0-4048AF305A2D@yahoo.com> In-Reply-To: <493AC0BE-3EC6-42B7-B027-FFB6454761B5@yahoo.com> References: <b0f5b62f-54fb-309f-a578-7b4d9e340a55@FreeBSD.org> <19343397-859C-4629-A4A5-B0DCDE25957B@yahoo.com> <AB56B3D1-1762-4115-B7B4-91D4B997F1C4@yahoo.com> <eff896f3-e385-9a12-5132-3884e69689ca@FreeBSD.org> <D0B83B01-5428-42F0-B785-221826AF7EC4@yahoo.com> <a1da2471-535d-1497-ddf3-93aa0d29df59@FreeBSD.org> <5AA68ED2-2615-438B-A6AE-406CBD8E49F7@yahoo.com> <20027C29-0093-4001-A135-23783F8B87F3@yahoo.com> <4048D2A4-7E14-481C-9B5D-00567BCF4463@yahoo.com> <2AAC9738-73BD-475A-888A-252EE853A5C6@yahoo.com> <493AC0BE-3EC6-42B7-B027-FFB6454761B5@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-Jan-22, at 19:19, Mark Millard <marklmi at yahoo.com> wrote: > On 2019-Jan-22, at 18:32, Mark Millard <marklm at yahoo.com> wrote: >=20 >=20 >=20 >> On 2019-Jan-22, at 17:06, Mark Millard <marklmi at yahoo.com> wrote: >>=20 >>=20 >>=20 >> . . . >> So I'm trying: >>=20 >> # git clean -f >> # rm */config.cache */*/config.cache >> # env CPATH=3D/usr/local/include ./configure >> . . . >> # env CPATH=3D/usr/local/include gmake >> . . . >>=20 >> in order to try to add paths after the command line -I paths. >>=20 >> . . . This looks like it built. I've not used the build yet. >>=20 >=20 > Looking at a *.core did not go well for my context: >=20 > # cc -g -O2 tls_gdb_test.c=20 > tls_gdb_test.c:16:2: warning: indirection of non-volatile null pointer = will be deleted, not trap [-Wnull-dereference] > *(char *)NULL =3D 1; > ^~~~~~~~~~~~~ > tls_gdb_test.c:16:2: note: consider using __builtin_trap() or = qualifying pointer with 'volatile' > 1 warning generated. > FBSDG5L# ./a.out > main: PID 70304 > id =3D 70304 (0x810054020) >=20 > Trace/BPT trap (core dumped) >=20 > # ppc64_tls_git/gdb/gdb a.out a.out.70304.core=20 > GNU gdb (GDB) 8.2.50.20190115-git > Copyright (C) 2019 Free Software Foundation, Inc. > . . . > Reading symbols from a.out... > [New LWP 100166] > Core was generated by `./a.out'. > Program terminated with signal SIGTRAP, Trace/breakpoint trap. > #0 main (ac=3D<optimized out>, av=3D<optimized out>) at = tls_gdb_test.c:16 > 16 *(char *)NULL =3D 1; > (gdb) bt > #0 main (ac=3D<optimized out>, av=3D<optimized out>) at = tls_gdb_test.c:16 > (gdb) p id > Cannot find thread-local storage for LWP 100166, executable file = /root/c_tests/a.out: > Cannot fetch runtime linker structure offsets > (gdb) p &id > Cannot find thread-local storage for LWP 100166, executable file = /root/c_tests/a.out: > Cannot fetch runtime linker structure offsets > (gdb)=20 >=20 >=20 > Trying running under the gdb variant got stuck with gdb looping = indefinately: >=20 > 70322 root 1 103 0 30M 20M 0 CPU2 2 3:12 = 101.06% ppc64_tls_git/gdb/gdb a.out >=20 > That was for: >=20 > # ppc64_tls_git/gdb/gdb a.out > GNU gdb (GDB) 8.2.50.20190115-git > Copyright (C) 2019 Free Software Foundation, Inc. > . . . >=20 > But I was able to ^C to get back to a (gdb) prompt and: >=20 > (gdb) p id > Cannot find thread-local storage for LWP 100111 of process 70323, = executable file /root/c_tests/a.out: > Cannot fetch runtime linker structure offsets > (gdb) p &id > Cannot find thread-local storage for LWP 100111 of process 70323, = executable file /root/c_tests/a.out: > Cannot fetch runtime linker structure offsets > (gdb) info threads > Id Target Id Frame=20 > * 1 LWP 100111 of process 70323 main (ac=3D<optimized out>, = av=3D<optimized out>) at tls_gdb_test.c:16 >=20 > So it looks to me to not be working with system-clang based compiles = of the example > test from the original E-mail. >=20 > But, looking around and using stepi ( with display/i $pc ) the code is = trying a trap instruction > over and over: >=20 > (gdb) disass > Dump of assembler code for function main: > 0x0000000010000adc <+0>: mflr r0 > 0x0000000010000ae0 <+4>: std r31,-8(r1) > 0x0000000010000ae4 <+8>: std r0,16(r1) > 0x0000000010000ae8 <+12>: stdu r1,-128(r1) > 0x0000000010000aec <+16>: mr r31,r1 > 0x0000000010000af0 <+20>: std r30,112(r31) > 0x0000000010000af4 <+24>: bl 0x10000600 = <00000017.plt_call.getpid@@FBSD_1.0> > 0x0000000010000af8 <+28>: ld r2,40(r1) > 0x0000000010000afc <+32>: mr r4,r3 > 0x0000000010000b00 <+36>: addis r3,r2,-2 > 0x0000000010000b04 <+40>: addi r3,r3,31952 > 0x0000000010000b08 <+44>: bl 0x100005e0 = <00000017.plt_call.printf@@FBSD_1.0> > 0x0000000010000b0c <+48>: ld r2,40(r1) > 0x0000000010000b10 <+52>: bl 0x10000600 = <00000017.plt_call.getpid@@FBSD_1.0> > 0x0000000010000b14 <+56>: ld r2,40(r1) > 0x0000000010000b18 <+60>: mr r30,r3 > 0x0000000010000b1c <+64>: nop > 0x0000000010000b20 <+68>: nop > 0x0000000010000b24 <+72>: addi r3,r13,4096 > 0x0000000010000b28 <+76>: nop > 0x0000000010000b2c <+80>: addis r3,r3,0 > 0x0000000010000b30 <+84>: mr r4,r30 > 0x0000000010000b34 <+88>: stw r30,-32768(r3) > 0x0000000010000b38 <+92>: addi r5,r3,-32768 > 0x0000000010000b3c <+96>: addis r3,r2,-2 > 0x0000000010000b40 <+100>: addi r3,r3,31966 > 0x0000000010000b44 <+104>: bl 0x100005e0 = <00000017.plt_call.printf@@FBSD_1.0> > 0x0000000010000b48 <+108>: ld r2,40(r1) > 0x0000000010000b4c <+112>: nop > 0x0000000010000b50 <+116>: nop > 0x0000000010000b54 <+120>: ld r3,-32728(r2) > 0x0000000010000b58 <+124>: ld r4,-32720(r2) > 0x0000000010000b5c <+128>: lwz r3,0(r3) > 0x0000000010000b60 <+132>: cmplwi r3,0 > 0x0000000010000b64 <+136>: ld r3,0(r4) > 0x0000000010000b68 <+140>: bne 0x10000b8c <main+176> > 0x0000000010000b6c <+144>: lwz r4,8(r3) > 0x0000000010000b70 <+148>: addi r5,r4,-1 > 0x0000000010000b74 <+152>: cmpwi r4,0 > 0x0000000010000b78 <+156>: stw r5,8(r3) > 0x0000000010000b7c <+160>: bgt 0x10000b98 <main+188> > 0x0000000010000b80 <+164>: bl 0x10000620 = <00000017.plt_call.__srget@@FBSD_1.0> > 0x0000000010000b84 <+168>: ld r2,40(r1) > =3D> 0x0000000010000b88 <+172>: trap > 0x0000000010000b8c <+176>: bl 0x10000640 = <00000017.plt_call.getc@@FBSD_1.0> > 0x0000000010000b90 <+180>: ld r2,40(r1) > 0x0000000010000b94 <+184>: trap > 0x0000000010000b98 <+188>: ld r4,0(r3) > 0x0000000010000b9c <+192>: addi r4,r4,1 > 0x0000000010000ba0 <+196>: std r4,0(r3) > 0x0000000010000ba4 <+200>: trap > 0x0000000010000ba8 <+204>: .long 0x0 > 0x0000000010000bac <+208>: .long 0x0 > 0x0000000010000bb0 <+212>: .long 0x0 > End of assembler dump. >=20 >=20 > I do not know if my context being a head -r341836 variant might = contribute > (too old?). >=20 > I may try some fairly modern gcc* variant(s) instead to see if that = makes a difference. >=20 > For reference: the compile of the test was based on using -g -O2 . So far all tried-combinations of using gcc versions for build the test program and/or building the gdb used do not work for "p id" and "p &id" in doing the test. clang is not essential to the behavior observed. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B07EC3F9-6C08-4B5D-89D0-4048AF305A2D>