From owner-freebsd-ppc@freebsd.org Wed Jan 23 18:10:58 2019 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BBE214AEC9D for ; Wed, 23 Jan 2019 18:10:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.ne1.yahoo.com (sonic310-22.consmr.mail.ne1.yahoo.com [66.163.186.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48F8E84F47 for ; Wed, 23 Jan 2019 18:10:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: iXLLbXgVM1lzB17Jp2VuPO_vk2gLG_G1AHNs7gRYxvxJrtYfXfrW0sy3xyUuhNd kPk.UB5VLVbcQvu.8jpB3CmGsNlVfxvnsfUBFgvOtmDjlt_fEeNFFL98YJvTT1GTMGhDVdirCGvN dFNzsQERglvypfH6BkUrBitslsXg6MHKtAFTKJ8dSHL_RAKFqSkJqEFdINhG4xVsWNuq6XheEUXH 0XUokxn6P3CpSPeZ856CGkoCa1Yxu9WeO7Zz7RtyI2Fa631.OD13n3kweCWyxV6fa3LcTdE8vN5. ef20anFniAq8bIsoq5v.1_4wfcmDUpbyJDy0gX_23MvobmBlVWyRudeDDOgxeNau.P8vGJxJoH3M tS57tkXyVrjnIcrhCtG22SxCTxpQEI39VNocvOQ4Ehxt14Oh48wAB_508PxOuYia3m3DG5dvcUDj Ri32AkakhJvmnZefs0zqIFlOFw8zoOYD..d_NtNfGTQzqbP0xv8uo_ECsYFa_dNfIbYVm5UkwfjF N1FImghp9Yq1KS.9B5ZcVwjsvtVB4SpESWiXVYdq3D9b1RItZyz6hMNWwmrvqjKzXn0i_jnc.iTm aOgK1iLKCv37hlUtPH61bc6ZOAeIz1MhsTexNaNo9CoXWILNU16cDb_Q4ZlGiRQ3AtpTffa5SfEY NaSCcKxaeyy7v0xN._PMUCwsFvbbVyfgLvKH1zmXvcTZQACBwmJPc0AfggNRXLYeyBqcpGstNQKY BRImONjesYGo.FfA6h3._PkoU46haeoi0N_0LhfooZ4SdYQ0z519bm63zFlY1VbAqVNfgsutrTQc RMx4_FJP8OkT_eGgFx5d24sDQroQ6AomyiLgAO.M4kj7Dy0Ff3R5L3euh6MZZtKz.VsCtyQC_IBu 06A_iYIi9TH2MRfppt61lsTkSsDo1d.GYULTDuCHPZlYENbu1dSDbIbTLg3ELXCSO41VE1a_qN1x WJstxZxcometxiSeWf5mhWJtxHCfRszS9rO65SWk9IjYbBB4noCt2z_sh5IBjZql4IHVPfyYtKxF VpE8b1G82ohN7DLsNHYTGLWs7lVZBvdEHPk3hlDbPrbreq9W.QQdlL2COEZwVJZOUVV3x_Wv_f8E - Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Wed, 23 Jan 2019 18:10:49 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.102]) ([67.170.167.181]) by smtp432.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e379fe9cf0132c93424912ff8e22dd17; Wed, 23 Jan 2019 18:10:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: GDB TLS testing [actually running some tests finally: a success with -pthread used] From: Mark Millard In-Reply-To: Date: Wed, 23 Jan 2019 10:10:43 -0800 Cc: "freebsd-ppc@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <20B92DA0-33B7-44D1-AB92-E3DD55A8B7CE@yahoo.com> References: <19343397-859C-4629-A4A5-B0DCDE25957B@yahoo.com> <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> <52E66D9B-C332-4565-B8E7-F54F6454B062@yahoo.com> To: John Baldwin X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 48F8E84F47 X-Spamd-Bar: / X-Spamd-Result: default: False [-0.46 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.03)[-0.032,0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.58)[-0.579,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.33)[-0.332,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.99)[ip: (3.08), ipnet: 66.163.184.0/21(1.09), asn: 36646(0.88), country: US(-0.08)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[203.186.163.66.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 18:10:58 -0000 On 2019-Jan-23, at 09:59, Mark Millard wrote: > On 2019-Jan-23, at 09:02, John Baldwin wrote: >=20 >> On 1/23/19 12:19 AM, Mark Millard wrote: >>>=20 >>>=20 >>> On 2019-Jan-22, at 22:53, Mark Millard wrote: >>>=20 >>>=20 >>>=20 >>>> On 2019-Jan-22, at 19:19, Mark Millard = wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> On 2019-Jan-22, at 18:32, Mark Millard = wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On 2019-Jan-22, at 17:06, Mark Millard = wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> . . . >>>>>> So I'm trying: >>>>>>=20 >>>>>> # git clean -f >>>>>> # rm */config.cache */*/config.cache >>>>>> # env CPATH=3D/usr/local/include ./configure >>>>>> . . . >>>>>> # env CPATH=3D/usr/local/include gmake >>>>>> . . . >>>>>>=20 >>>>>> in order to try to add paths after the command line -I paths. >>>>>>=20 >>>>>> . . . This looks like it built. I've not used the build yet. >>>>>>=20 >>>>>=20 >>>>> Looking at a *.core did not go well for my context: >>>>>=20 >>>>> # cc -g -O2 tls_gdb_test.c=20 >>>>> tls_gdb_test.c:16:2: warning: indirection of non-volatile null = pointer will be deleted, not trap [-Wnull-dereference] >>>>> *(char *)NULL =3D 1; >>>>> ^~~~~~~~~~~~~ >>>>> tls_gdb_test.c:16:2: note: consider using __builtin_trap() or = qualifying pointer with 'volatile' >>>>> 1 warning generated. >>=20 >> For me, builtin_trap didn't DTRT on ppc before, but that was probably = using >> gcc rather than clang (and possibly using gcc4.2). >>=20 >>>>> . . . >>>>=20 >>>>=20 >>>> 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. >>>=20 >>> Using "-g -O2 -pthread" to build the test program via system >>> clang or gcc8 (for example) did lead to the likes of: >>>=20 >>> (gdb) run=20 >>> Starting program: /root/c_tests/a.out=20 >>> main: PID 15350 >>> id =3D 15350 (0x810055020) >>>=20 >>> ^C >>> Program received signal SIGINT, Interrupt. >>> main (ac=3D, av=3D) at = tls_gdb_test.c:16 >>> 16 *(char *)NULL =3D 1; >>> (gdb) bt >>> #0 main (ac=3D, av=3D) at = tls_gdb_test.c:16 >>> (gdb) info threads >>> Id Target Id Frame=20 >>> * 1 LWP 100324 of process 15350 main (ac=3D, = av=3D) at tls_gdb_test.c:16 >>> (gdb) p id >>> $1 =3D 15350 >>> (gdb) p &id >>> $2 =3D (int *) 0x810055020 >>>=20 >>> So it appears one branch of: >>>=20 >>> 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 =3D parse_and_eval_long ("&((Obj_Entry = *)0)->linkmap"); >>> data->off_tlsindex =3D parse_and_eval_long ("&((Obj_Entry = *)0)->tlsindex"); >>> data->rtld_offsets_valid =3D true; >>> return; >>> } >>> CATCH (e, RETURN_MASK_ERROR) >>> { >>> data->off_linkmap =3D -1; >>> } >>> END_CATCH >>>=20 >>> 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 =3D fbsd_read_integer_by_name(gdbarch, >>> = "_thread_off_linkmap"); >>> data->off_tlsindex =3D fbsd_read_integer_by_name(gdbarch, >>> = "_thread_off_tlsindex"); >>> data->rtld_offsets_valid =3D true; >>> return; >>> } >>> CATCH (e, RETURN_MASK_ERROR) >>> { >>> data->off_linkmap =3D -1; >>> } >>> END_CATCH >>> } >>>=20 >>> is working when -pthread is used. >>=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 . 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 =3D (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? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)