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

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 .

===
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]"