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

[Mark Millard]

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



> On 2019-Jan-23, at 10:43, John Baldwin <jhb at FreeBSD.org> wrote:
> 
>> On 1/23/19 10:10 AM, Mark Millard wrote:
>>> 
>>> 
>>> 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:
>>>> 
>>>>>> . . .
>>>>> 
>>>>> 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?
>> 
>> Oh, it might not have /usr/lib/debug configured as a debug directory.  I
>> usually use a wrapper script (available at github/bsdjhb/kdbg.git/gdb/build)
>> which sets various configure options to match what the port does.  One of
>> those is --with-separate-debug-dir=/usr/lib/debug which will probably fix
>> this.
> 
> The script does things not matching how I'm working but gives me a
> reference for what you do.
> 
> So initally I'm trying:
> 
> # git clean -f
> # rm */config.cache */*/config.cache
> # env CPATH=/usr/local/include ./configure --with-separate-debug-dir=/usr/lib/debug
> . . .
> # env CPATH=/usr/local/include gmake
> . . .
> 

This was sufficient for making the case of a lack of -pthread
also "p id" and "p &id" in gdb correctly in for the test
program from the original list message in my powerpc64 context.


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