GDB TLS testing [actually running some tests finally but these tests fail]
Mark Millard
marklmi at yahoo.com
Wed Jan 23 06:54:01 UTC 2019
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)
More information about the freebsd-ppc
mailing list