Re: GDB TLS testing [actually running some tests finally but these tests fail]

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:
> 
> 
> 
>> On 2019-Jan-22, at 17:06, Mark Millard <marklmi at yahoo.com> wrote:
>> 
>> 
>> 
>> . . .
>> So I'm trying:
>> 
>> # git clean -f
>> # rm */config.cache */*/config.cache
>> # env CPATH=/usr/local/include ./configure
>> . . .
>> # env CPATH=/usr/local/include gmake
>> . . .
>> 
>> in order to try to add paths after the command line -I paths.
>> 
>> . . . This looks like it built. I've not used the build yet.
>> 
> 
> Looking at a *.core did not go well for my context:
> 
> # cc -g -O2 tls_gdb_test.c 
> tls_gdb_test.c:16:2: warning: indirection of non-volatile null pointer will be deleted, not trap [-Wnull-dereference]
>        *(char *)NULL = 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 = 70304 (0x810054020)
> 
> Trace/BPT trap (core dumped)
> 
> # ppc64_tls_git/gdb/gdb a.out a.out.70304.core 
> 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=<optimized out>, av=<optimized out>) at tls_gdb_test.c:16
> 16		*(char *)NULL = 1;
> (gdb) bt
> #0  main (ac=<optimized out>, av=<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) 
> 
> 
> Trying running under the gdb variant got stuck with gdb looping indefinately:
> 
> 70322 root          1 103    0    30M    20M    0 CPU2     2   3:12 101.06% ppc64_tls_git/gdb/gdb a.out
> 
> That was for:
> 
> # ppc64_tls_git/gdb/gdb a.out
> GNU gdb (GDB) 8.2.50.20190115-git
> Copyright (C) 2019 Free Software Foundation, Inc.
> . . .
> 
> But I was able to ^C to get back to a (gdb) prompt and:
> 
> (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 
> * 1    LWP 100111 of process 70323 main (ac=<optimized out>, av=<optimized out>) at tls_gdb_test.c:16
> 
> So it looks to me to not be working with system-clang based compiles of the example
> test from the original E-mail.
> 
> But, looking around and using stepi ( with display/i $pc ) the code is trying a trap instruction
> over and over:
> 
> (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)
> => 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.
> 
> 
> I do not know if my context being a head -r341836 variant might contribute
> (too old?).
> 
> I may try some fairly modern gcc* variant(s) instead to see if that makes a difference.
> 
> 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.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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