Date: Wed, 23 Jan 2019 10:43:25 -0800 From: John Baldwin <jhb@FreeBSD.org> To: Mark Millard <marklmi@yahoo.com> Cc: "freebsd-ppc@freebsd.org" <freebsd-ppc@FreeBSD.org> Subject: Re: GDB TLS testing [actually running some tests finally: a success with -pthread used] Message-ID: <a0c9a35b-95a8-0cd9-6e77-07c858be9328@FreeBSD.org> In-Reply-To: <20B92DA0-33B7-44D1-AB92-E3DD55A8B7CE@yahoo.com> References: <b0f5b62f-54fb-309f-a578-7b4d9e340a55@FreeBSD.org> <19343397-859C-4629-A4A5-B0DCDE25957B@yahoo.com> <AB56B3D1-1762-4115-B7B4-91D4B997F1C4@yahoo.com> <eff896f3-e385-9a12-5132-3884e69689ca@FreeBSD.org> <D0B83B01-5428-42F0-B785-221826AF7EC4@yahoo.com> <a1da2471-535d-1497-ddf3-93aa0d29df59@FreeBSD.org> <5AA68ED2-2615-438B-A6AE-406CBD8E49F7@yahoo.com> <20027C29-0093-4001-A135-23783F8B87F3@yahoo.com> <4048D2A4-7E14-481C-9B5D-00567BCF4463@yahoo.com> <2AAC9738-73BD-475A-888A-252EE853A5C6@yahoo.com> <493AC0BE-3EC6-42B7-B027-FFB6454761B5@yahoo.com> <B07EC3F9-6C08-4B5D-89D0-4048AF305A2D@yahoo.com> <52E66D9B-C332-4565-B8E7-F54F6454B062@yahoo.com> <a0e02258-3e43-fb91-566d-29b48fe81e77@FreeBSD.org> <DBF4C75D-213E-42E2-8682-6B3078FCB8D5@yahoo.com> <20B92DA0-33B7-44D1-AB92-E3DD55A8B7CE@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
>>
>>> On 1/23/19 12:19 AM, Mark Millard wrote:
>>>>
>>>>
>>>> On 2019-Jan-22, at 22:53, Mark Millard <marklmi@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?
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.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a0c9a35b-95a8-0cd9-6e77-07c858be9328>