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

[Mark Millard]

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 .
                                                                            

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