GDB TLS testing [actually running some tests finally: a success with -pthread used]

[Mark Millard]

On 2019-Jan-23, at 09:59, Mark Millard <marklmi at yahoo.com> wrote:



> On 2019-Jan-23, at 09:02, John Baldwin <jhb at FreeBSD.org> wrote:
> 
>> On 1/23/19 12:19 AM, Mark Millard wrote:
>>> 
>>> 
>>> On 2019-Jan-22, at 22:53, Mark Millard <marklmi at yahoo.com> wrote:
>>> 
>>> 
>>> 
>>>> 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.
>> 
>> For me, builtin_trap didn't DTRT on ppc before, but that was probably using
>> gcc rather than clang (and possibly using gcc4.2).
>> 
>>>>> . . .
>>>> 
>>>> 
>>>> 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.
>>> 
>>> Using "-g -O2 -pthread" to build the test program via system
>>> clang or gcc8 (for example) did lead to the likes of:
>>> 
>>> (gdb) run 
>>> Starting program: /root/c_tests/a.out 
>>> main: PID 15350
>>> id = 15350 (0x810055020)
>>> 
>>> ^C
>>> Program received signal SIGINT, Interrupt.
>>> 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) info threads
>>> Id   Target Id                   Frame 
>>> * 1    LWP 100324 of process 15350 main (ac=<optimized out>, av=<optimized out>) at tls_gdb_test.c:16
>>> (gdb) p id
>>> $1 = 15350
>>> (gdb) p &id
>>> $2 = (int *) 0x810055020
>>> 
>>> So it appears one branch of:
>>> 
>>> static void
>>> fbsd_fetch_rtld_offsets (struct gdbarch *gdbarch, struct fbsd_pspace_data *data)
>>> {
>>> TRY
>>>   {
>>>     /* Fetch offsets from debug symbols in rtld.  */
>>>     data->off_linkmap = parse_and_eval_long ("&((Obj_Entry *)0)->linkmap");
>>>     data->off_tlsindex = parse_and_eval_long ("&((Obj_Entry *)0)->tlsindex");
>>>     data->rtld_offsets_valid = true;
>>>     return;
>>>   }
>>> CATCH (e, RETURN_MASK_ERROR)
>>>   {
>>>     data->off_linkmap = -1;
>>>   }
>>> END_CATCH
>>> 
>>> TRY
>>>   {
>>>     /* Fetch offsets from global variables in libthr.  Note that
>>>        this does not work for single-threaded processes that are not
>>>        linked against libthr.  */
>>>     data->off_linkmap = fbsd_read_integer_by_name(gdbarch,
>>>                                                   "_thread_off_linkmap");
>>>     data->off_tlsindex = fbsd_read_integer_by_name(gdbarch,
>>>                                                    "_thread_off_tlsindex");
>>>     data->rtld_offsets_valid = true;
>>>     return;
>>>   }
>>> CATCH (e, RETURN_MASK_ERROR)
>>>   {
>>>     data->off_linkmap = -1;
>>>   }
>>> END_CATCH
>>> }
>>> 
>>> is working when -pthread is used.
>> 
>> Yes.  The second one only works for programs linked against -lthr.  Otherwise
>> you need to have built your system with debug symbols (which is the default),
>> and gdb needs to be able to access /usr/lib/debug/libexec/ld-elf.so.1.debug
>> to determine the offsets of the two fields in Obj_Entry (this is what the
>> first TRY clause does).
> 
> I buildworld buildkernel with debug symbols for both and install them:
> 
> # ls -lT /usr/lib/debug/libexec/ld-elf.so.1.debug
> -r--r--r--  1 root  wheel  576344 Dec 11 22:58:11 2018 /usr/lib/debug/libexec/ld-elf.so.1.debug
> 
> # ls -lT /usr/libexec/ld-elf.so.1 /libexec/ld-elf.so.1
> -r-xr-xr-x  1 root  wheel  184400 Dec  9 02:35:05 2018 /libexec/ld-elf.so.1
> lrwxr-xr-x  1 root  wheel      25 Dec 11 22:58:12 2018 /usr/libexec/ld-elf.so.1 -> ../../libexec/ld-elf.so.1
> 
> So I think the first TRY clause does not work.
> 
> In the tested gdb used on the a.out I'm testing I get:
> 
> (gdb) p &((Obj_Entry *)0)->linkmap
> No symbol "Obj_Entry" in current context.
> 
> gdb does not report reading symbols from or for:
> 
> /usr/lib/debug/libexec/ld-elf.so.1.debug
> or:
> /usr/libexec/ld-elf.so.1
> or:
> /libexec/ld-elf.so.1
> 
> It only reports reading them from/for the a.out .

It neded up that I had a littel time so . . .

I tried /usr/local/bin/gdb and for it:

(gdb) p &((Obj_Entry *)0)->linkmap
$1 = (struct link_map *) 0x238

So the lack of finding Obj_Entry via the test gdb seems to be
specific to the test gdb, not a problem for devel/gdb .

May be the test gdb has some sort of build problem in my context,
given that I used CPATH to get things to build?


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