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>