Date: Wed, 23 Jan 2019 13:46:45 -0800 From: Mark Millard <marklmi@yahoo.com> To: John Baldwin <jhb@FreeBSD.org> 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: <0C2BB5BF-F133-4D23-8462-E015CDAC21C7@yahoo.com> In-Reply-To: <a0c9a35b-95a8-0cd9-6e77-07c858be9328@FreeBSD.org> 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> <a0c9a35b-95a8-0cd9-6e77-07c858be9328@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-Jan-23, at 10:43, John Baldwin <jhb at FreeBSD.org> wrote:
> On 1/23/19 10:10 AM, Mark Millard wrote:
>>=20
>>=20
>> On 2019-Jan-23, at 09:59, Mark Millard <marklmi at yahoo.com> wrote:
>>=20
>>=20
>>=20
>>> On 2019-Jan-23, at 09:02, John Baldwin <jhb at FreeBSD.org> wrote:
>>>=20
>>>>> . . .
>>>>=20
>>>> 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).
>>>=20
>>> I buildworld buildkernel with debug symbols for both and install =
them:
>>>=20
>>> # 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
>>>=20
>>> # 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
>>>=20
>>> So I think the first TRY clause does not work.
>>>=20
>>> In the tested gdb used on the a.out I'm testing I get:
>>>=20
>>> (gdb) p &((Obj_Entry *)0)->linkmap
>>> No symbol "Obj_Entry" in current context.
>>>=20
>>> gdb does not report reading symbols from or for:
>>>=20
>>> /usr/lib/debug/libexec/ld-elf.so.1.debug
>>> or:
>>> /usr/libexec/ld-elf.so.1
>>> or:
>>> /libexec/ld-elf.so.1
>>>=20
>>> It only reports reading them from/for the a.out .
>>=20
>> It neded up that I had a littel time so . . .
>>=20
>> I tried /usr/local/bin/gdb and for it:
>>=20
>> (gdb) p &((Obj_Entry *)0)->linkmap
>> $1 =3D (struct link_map *) 0x238
>>=20
>> 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 .
>>=20
>> May be the test gdb has some sort of build problem in my context,
>> given that I used CPATH to get things to build?
>=20
> 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=3D/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=3D/usr/local/include ./configure =
--with-separate-debug-dir=3D/usr/lib/debug
. . .
# env CPATH=3D/usr/local/include gmake
. . .
I will note that there are oddities like:
tree.c:542:45: warning: 'memset' call operates on objects of type =
'device_unit' (aka 'struct _device_unit') while the size is based on a =
different type 'device_unit *' (aka 'struct _device_unit *')
[-Wsizeof-pointer-memaccess]
memset(®s[reg_nr].size, 0, sizeof (®s[reg_nr].size));
~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~
tree.c:542:45: note: did you mean to remove the addressof in the =
argument to 'sizeof' (and multiply it by the number of elements)?
memset(®s[reg_nr].size, 0, sizeof (®s[reg_nr].size));
^~~~~~~~~~~~~~~~~~
There are a fair number of the likes of:
warning: format specifies type 'unsigned long' but the argument has type =
'unsigned_word' (aka 'unsigned int') [-Wformat]
indicating 32-bit formats for 64 bit values (the context is powerpc64). =
There are
also examples the reverse.
=
=20
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0C2BB5BF-F133-4D23-8462-E015CDAC21C7>