From owner-freebsd-ppc@freebsd.org Tue Jan 22 17:51:18 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 C3A6214A9AB7 for ; Tue, 22 Jan 2019 17:51:17 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 285B29610A; Tue, 22 Jan 2019 17:51:17 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id AC6CDBC71; Tue, 22 Jan 2019 17:51:16 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: GDB TLS testing To: Mark Millard Cc: "freebsd-ppc@freebsd.org" References: <19343397-859C-4629-A4A5-B0DCDE25957B@yahoo.com> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Tue, 22 Jan 2019 09:50:20 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 285B29610A X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.94 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.95)[-0.946,0]; NEURAL_HAM_LONG(-1.00)[-1.000,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: Tue, 22 Jan 2019 17:51:18 -0000 On 1/21/19 7:02 PM, Mark Millard wrote: > > > On 2019-Jan-21, at 18:24, Mark Millard wrote: > > > >> On 2019-Jan-21, at 12:58, John Baldwin wrote: >> >>> . . . >>> >>> Would someone with a working ppc system be willing to help test the GDB bits >>> for me? You can grab the 'fbsd_tls' branch from github/bsdjhb/gdb.git to >>> build a GDB. For testing purposes, just generating a core from the test >>> programs I'm using and looking at that core on a non-ppc host would also >>> work fine. For example, in my case where I have the ppc system installed to >>> /qemu/ppc64/rootfs, I would do 'set sysroot /qemu/ppc64/rootfs' at the GDB >>> prompt to point GDB at the ppc64 libraries, etc. Note that modern GDB is >>> written in C++11, so you can't build it with gcc4.2. >>> >>> The first test program I am using is below and should generate a core when >>> run. To test the TLS functionality you would want to make sure 'p id' >>> reports the proper value (PID from the program's output), and also that >>> 'p &id' also reports an address matching the program's output: >>> >>> #include >>> #include >>> >>> static __thread int id; >>> >>> int >>> main(int ac, char **av) >>> { >>> >>> printf("main: PID %d\n", getpid()); >>> id = getpid(); >>> printf("id = %d (%p)\n", id, &id); >>> (void)getchar(); >>> #if 1 >>> #if defined(__powerpc__) >>> *(char *)NULL = 1; >>> #else >>> __builtin_trap(); >>> #endif >>> #endif >>> return (0); >>> } >> >> Note: This is from my odd devel/pwoerpc64-xtoolchain-gcc based buildworld >> based environment with cc being system clang: >> >> # uname -apKU >> FreeBSD FBSDG5L 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r341836M: Tue Dec 11 20:11:21 PST 2018 markmi@FBSDFSSD:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1300005 1300005 >> >> >> Absent makeinfo the make failed to complete. (I've no clue if there are >> more dependencies required.) >> >> # ./configure >> checking build system type... powerpc64-unknown-freebsd13.0 >> checking host system type... powerpc64-unknown-freebsd13.0 >> checking target system type... powerpc64-unknown-freebsd13.0 >> checking for a BSD-compatible install... /usr/bin/install -c >> . . . >> checking for makeinfo... no >> /root/c_tests/ppc64_tls_git/missing: makeinfo: not found >> checking for expect... no >> . . . >> # make >> Configuring in ./libiberty >> configure: creating cache ./config.cache >> checking whether to enable maintainer-specific portions of Makefiles... no >> checking for makeinfo... /root/c_tests/ppc64_tls_git/missing makeinfo --split-size=5000000 >> configure: WARNING: >> *** Makeinfo is missing. Info documentation will not be built. >> checking for perl... perl >> . . . >> creating bfdver.texi >> restore=: && backupdir=".am$$" && rm -rf $backupdir && mkdir $backupdir && if (/root/c_tests/ppc64_tls_git/missing makeinfo --split-size=5000000 --split-size=5000000 --version) >/dev/null 2>&1; then for f in bfd.info bfd.info-[0-9] bfd.info-[0-9][0-9] bfd.i[0-9] bfd.i[0-9][0-9]; do if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; done; else :; fi && if /root/c_tests/ppc64_tls_git/missing makeinfo --split-size=5000000 --split-size=5000000 -I . -o bfd.info `test -f 'bfd.texi' || echo './'`bfd.texi; then rc=0; else rc=$?; $restore $backupdir/* `echo "./bfd.info" | sed 's|[^/]*$||'`; fi; rm -rf $backupdir; exit $rc >> /root/c_tests/ppc64_tls_git/missing: makeinfo: not found >> WARNING: 'makeinfo' is missing on your system. >> You should only need it if you modified a '.texi' file, or >> any other file indirectly affecting the aspect of the manual. >> You might want to install the Texinfo package: >> >> The spurious makeinfo call might also be the consequence of >> using a buggy 'make' (AIX, DU, IRIX), in which case you might >> want to install GNU make: >> >> *** Error code 127 >> >> Stop. >> make[3]: stopped in /root/c_tests/ppc64_tls_git/bfd/doc >> *** Error code 1 >> >> Stop. >> make[2]: stopped in /root/c_tests/ppc64_tls_git/bfd >> *** Error code 1 >> >> Stop. >> make[1]: stopped in /root/c_tests/ppc64_tls_git >> *** Error code 1 >> >> Stop. >> make: stopped in /root/c_tests/ppc64_tls_git > > > After installing print/texinfo to get makeinfo , the > next problem for me is libintl.h not being found > despite its existence in /usr/local/include/ : > > # make > . . . > libtool: compile: cc -DHAVE_CONFIG_H -I. -DBINDIR=\"/usr/local/bin\" -I. -I. -I./../include -DHAVE_powerpc_elf64_fbsd_vec -DHAVE_powerpc_elf64_vec -DHAVE_powerpc_elf32_vec -DHAVE_powerpc_elf32_fbsd_vec -DHAVE_powerpc_elf32_le_vec -DHAVE_rs6000_xcoff_vec -DHAVE_rs6000_xcoff64_vec -DHAVE_rs6000_xcoff64_aix_vec -DHAVE_elf64_le_vec -DHAVE_elf64_be_vec -DHAVE_elf32_le_vec -DHAVE_elf32_be_vec -DHAVE_plugin_vec -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -I./../zlib -g -O2 -MT archive.lo -MD -MP -MF .deps/archive.Tpo -c archive.c -o archive.o > In file included from archive.c:134: > ./sysdep.h:185:11: fatal error: 'libintl.h' file not found > # include > ^~~~~~~~~~~ > 1 error generated. > *** Error code 1 > > Stop. > make[4]: stopped in /root/c_tests/ppc64_tls_git/bfd > *** Error code 1 > > Stop. > make[3]: stopped in /root/c_tests/ppc64_tls_git/bfd > *** Error code 1 > > Stop. > make[2]: stopped in /root/c_tests/ppc64_tls_git/bfd > *** Error code 1 > > Stop. > make[1]: stopped in /root/c_tests/ppc64_tls_git > *** Error code 1 > > Stop. > make: stopped in /root/c_tests/ppc64_tls_git > > > > # find /usr/local/include/ -name libintl.h -print > /usr/local/include/libintl.h This is an issue with GDB's configure that I haven't not been able to fix. I usually use a wrapper script, but it should be sufficient to set CFLAGS to "-I/usr/local/include" in the environment when invoking ./configure. Nevertheless, I was able to use a FAT filesystem image as a side car (as suggested by Justin) to examine the core dumps in a cross-debugger which was enough to test my current TLS patch: % ~/work/git/gdb/obj/gdb/gdb tls_single GNU gdb (GDB) 8.2.50.20190115-git ... Reading symbols from tls_single... Reading symbols from /usr/home/john/work/johnsvn/test/tls_single/ppc64/tls_single.debug... (gdb) set sysroot /qemu/ppc64/rootfs/ (gdb) core-file tls_single.core [New LWP 100058] Core was generated by `./tls_single'. Program terminated with signal SIGSEGV, Segmentation fault. Python Exception 'module' object has no attribute 'objfiles': #0 0x00000000100006bc in main (ac= , av=) at tls_single. c:16 16 *(char *)NULL = 1; (gdb) p id $1 = 688 (gdb) info proc process 688 cmdline = './tls_single' cwd = '/root' exe = '/root/tls_single' Hopefully this will land in GDB 8.3 when it is released. (Still need to get C++ exceptions working to have a functional native GDB for powerpc64 though.) -- John Baldwin