Date: Fri, 25 Jan 2019 00:06:09 -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: <AA978A72-71E3-4A8E-AF67-7000183812E1@yahoo.com> In-Reply-To: <0C2BB5BF-F133-4D23-8462-E015CDAC21C7@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> <a0c9a35b-95a8-0cd9-6e77-07c858be9328@FreeBSD.org> <0C2BB5BF-F133-4D23-8462-E015CDAC21C7@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=20 >> 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. >=20 > The script does things not matching how I'm working but gives me a > reference for what you do. >=20 > So initally I'm trying: >=20 > # 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 > . . . >=20 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. =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?AA978A72-71E3-4A8E-AF67-7000183812E1>