From owner-svn-src-head@freebsd.org Wed Nov 7 03:42:54 2018 Return-Path: Delivered-To: svn-src-head@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 CCD07110AF92 for ; Wed, 7 Nov 2018 03:42:54 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic303-21.consmr.mail.gq1.yahoo.com (sonic303-21.consmr.mail.gq1.yahoo.com [98.137.64.202]) (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 1E6EF7E5C4 for ; Wed, 7 Nov 2018 03:42:54 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: mAKSiAIVM1lxI1_NixwBDjgt7tuwxSr_zyzaTocjnnii0ToPRqSFCbs6x1Jumd6 DX6ypi6zs.nGIsKp0z.ryv_dXBIkKuqkCS7gjyxAEKQFi0qvaKjssVNAPnuPQYeUEYOXFI9BnIyK LNESxJAXAsgeMUVfSqHxaznCQfJ4xF5zbRaZjnpZ88xB7u06Gxq4wPI3IFM8UQGiXOivlWbFwMBI MPdEja5jktJFemQJM4ijOdNvudn.fpwwnxzPFj6DcU7XS3UXHuGbqQYTJhDshR22C3trJFFOpIZp TRmcvnLHl.eVs.INUXdOhKrG7PKw8PYJm_E27d6STZmNcRnyEGwEuZfFJY9iEeBBNS5CJNP9oy6g nLEklpMLuOkYRp9eVrxi2SHOQbkIvdPxjh2siJYOLFvoZt9elMha4AndjYBR_W9wg6zJeMVq0VTX QSAGc5jytyy7JkpnQObg_wtAizFU9U8SJ5Ib8WFmKct_QqgCiifXAj2e.hMNEhhyyhbtpymg4t4v 2VcKkvihxn0ypJMVu4R0ssdVQQfYyCel8_6fuKoJV5_.kgqHJ1Duq.xP6t5EXG2S8nZgiZSjbW9X xy4qoZB93hbraIInujbgpfFENsaz9nVGyulpkz3_A.Zok5luJVfYqK9IBzmjTxpwAQsdEr4xZ8gj GuQs8g.16a1bCNh.cy7mVll0IyNtK7385belHDpVg1CiysYrGcAR995iGrenlQERnTZv.77tXen9 pJS.j9yCP6yq8i5Y7Ya1pkodl5qisQFoloTdJSq.7yO4oqc_4VNVaNfgm5XUXhdMo_0abBxTslRG tRbAue1VngeV8KvCHO864s8Y2a9uw4z4FwWpPw4cwbjj9PhSI9a.kCw..ecLcTh_Z.yw6Ik2tQkU XC_PyPBCRV3KxbA6Fo5itQl59izbtVO6QaOgvfcg02YBwGGSeUrj56edkJjHxvZHFFD.APz7oCDC r1O618sATs57EclcOOOqFj8C6rbGbS8cFWu9.r65wqgoqIdIv82aMJwG6I8sSD7pv2qT0gya.QWI JZ86ThbwSUlbJ7g8z_L8Ryuv04VOWC4NJ2TZAeN40_0Q1X68- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 7 Nov 2018 03:42:47 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp403.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID da931776c6a69aa625d2b63b380ee953; Wed, 07 Nov 2018 03:12:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Subject: Re: svn commit: r339876 - head/libexec/rtld-elf From: Mark Millard In-Reply-To: <20181102185014.GP5335@kib.kiev.ua> Date: Tue, 6 Nov 2018 19:12:22 -0800 Cc: svn-src-head@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8FFCF603-6315-4D1C-858B-FC7233C17DD7@yahoo.com> References: <8E5A5F3A-F1A7-4702-A2F7-65D74CC5B2E5@yahoo.com> <20181102004101.GI5335@kib.kiev.ua> <003A49D7-6E8B-4775-A70B-E0EB44505D4B@yahoo.com> <20181102113827.GM5335@kib.kiev.ua> <7B29A4C8-228D-41CB-B594-98DFA456E9C8@yahoo.com> <20181102155234.GN5335@kib.kiev.ua> <20181102185014.GP5335@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3445.101.1) X-Rspamd-Queue-Id: 1E6EF7E5C4 X-Spamd-Result: default: False [-3.23 / 200.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.84)[-0.836,0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.11)[ipnet: 98.137.64.0/21(0.36), asn: 36647(0.28), country: US(-0.08)]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; R_DKIM_ALLOW(-0.20)[yahoo.com]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[202.64.137.98.list.dnswl.org : 127.0.5.0] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 03:42:55 -0000 [I've present a little information about the longer-existing failure's odd backtrace for /libexec/ld-elf.so.1 /bin/ls --but on powerpc64 FreeBSD instead of 32-bit powerpc FreeBSD.] On 2018-Nov-2, at 11:50, Konstantin Belousov = wrote: > On Fri, Nov 02, 2018 at 10:38:08AM -0700, Mark Millard wrote: >> On 2018-Nov-2, at 8:52 AM, Konstantin Belousov wrote: >>=20 >>> . . . >>=20 >> That seems better. But it crashes during /bin/ls execution >> ( 0x0180???? addresses ), apparently in a library routine >> ( 0x41?????? addresses ): >>=20 >> Program received signal SIGSEGV, Segmentation fault. >> 0x411220b4 in ?? () >> (gdb) bt >> #0 0x411220b4 in ?? () >> #1 0x4112200c in ?? () >> #2 0x01803c84 in ?? () >> #3 0x018023b4 in ?? () >> #4 0x010121a0 in .rtld_start () at = /usr/src/libexec/rtld-elf/powerpc/rtld_start.S:112 >>=20 >> Using a normal gdb run of /bin/ls suggests: >>=20 >> #2 0x01803c84 in ?? () should be in main and seems to be: bl = 0x1818914 >> #3 0x018023b4 in ?? () should be in _start >>=20 >> Looking in the test context: >>=20 >> 0x1803c80: bl 0x1818914 >> 0x1803c84: cmpwi cr7,r3,-1 >>=20 >> and: >>=20 >> 0x1818914: li r11,59 >> 0x1818918: b 0x18186f4 >>=20 >> and: >>=20 >> 0x18186f4: rlwinm r11,r11,2,0,29 >> 0x18186f8: addis r11,r11,386 >> 0x18186fc: lwz r11,-30316(r11) >> 0x1818700: mtctr r11 >> 0x1818704: bctr >>=20 >> Breaking at the bctr and using info reg: >>=20 >> r11 0x4125ffa0 1093009312 >>=20 >> It looks like there is some amount of >> activity before the traceback addresses >> show up. >>=20 >> I've not found a good way to fill in the "in ??()" >> (or analogous) information. The addresses 0x411220?? >> do not match up with a normal run of /bin/ls from >> gdb: the addresses can not be accessed. >>=20 >>=20 >>=20 >> It does appear that the code is in /lib/libc.so.7 in the >> test context: >>=20 >> Breakpoint 2, reloc_non_plt (obj=3D0x41041600, obj_rtld=3D0x41104b57, = flags=3D4, lockstate=3D0x0) at = /usr/src/libexec/rtld-elf/powerpc/reloc.c:338 >> . . . >>=20 > There seems to be an issue with the direct execution mode on ppc. > Even otherwise working ld-elf.so.1 segfaults if I try to use it as > standalone binary. >=20 > But if I specify patched ld-elf.so.1 as the interpreter for some = program, > using 'cc -Wl,-I,/ld-elf.so.1' it works. So I see there two = bugs, > one is regression due to textsize calculation, which should be fixed = by > my patch. Another is the direct exec problem. I've got a little more information about the odd backtrace from the /libexec/ld-elf.so.1 /bin/ls failure that the prior patch allowed getting to, although for a powerpc64 example context. The information is only identifying where the code was in /bin/ls and /lib/libc.so.1 in the backtrace. For libc.so.1 I found the same code sequences in a gdb of /bin/ls directly, matching one first, using the addresses vs. in the /libexec/ld-elf.so.1 /bin/ls process to find offsets for going back and forth, and then used that two find the 2nd backtrace addresses material. Overall it suggests to me that (in somewhat=20 symbolic terms): bl <00001322.plt_call.getenv> eventually lead to executing the wrong code. The supporting detail is as follows. The /libexec/ld-elf.so.1 part of the backtrace was easy to find where the code was: (gdb) run /bin/ls Starting program: /libexec/ld-elf.so.1 /bin/ls Program received signal SIGSEGV, Segmentation fault. 0x000000080118d81c in ?? () (gdb) bt #0 0x000000080118d81c in ?? () #1 0x000000080118d920 in ?? () #2 0x0000000010002558 in ?? () #3 0x00000000100037b0 in ?? () #4 0x0000000001018450 in ._rtld_start () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 Backtrace stopped: frame did not save the PC (gdb)=20 101 ld %r7,128(%r1) /* exit proc */ 102 ld %r8,136(%r1) /* ps_strings */ 103=09 104 blrl /* _start(argc, argv, envp, obj, cleanup, = ps_strings) */ 105=09 106 li %r0,1 /* _exit() */ 107 sc The /bin/ls part of the backtrace was easy to find were the code was: (gdb) symbol-file /bin/ls Load new symbol table from "/bin/ls"? (y or n) y Reading symbols from /bin/ls...Reading symbols from = /usr/lib/debug//bin/ls.debug...done. done. (gdb) bt #0 0x000000080118d81c in ?? () #1 0x000000080118d920 in ?? () #2 0x0000000010002558 in main (argc=3D, = argv=3D0x80134bdb0) at /usr/src/bin/ls/ls.c:268 #3 0x00000000100037b0 in _start (argc=3D, = argv=3D0x3fffffffffffdb70, env=3D0x3fffffffffffdb88, obj=3D, cleanup=3D, ps_strings=3D) at /usr/src/lib/csu/powerpc64/crt1.c:96 #4 0x0000000001018450 in ?? () #5 0x0000000000000000 in ?? () (gdb) fr 3=20 #3 0x00000000100037b0 in _start (argc=3D, = argv=3D0x3fffffffffffdb70, env=3D0x3fffffffffffdb88, obj=3D, cleanup=3D, ps_strings=3D) at /usr/src/lib/csu/powerpc64/crt1.c:96 96 exit(main(argc, argv, env)); (gdb) down #2 0x0000000010002558 in main (argc=3D, = argv=3D0x80134bdb0) at /usr/src/bin/ls/ls.c:268 268 while ((ch =3D getopt_long(argc, argv, For the messy lib.libc.so.1 part of the backtrace both addresses are in getopt_internal. I show extractions from the the gdb /bin/ls output because it has helpful symbolic information displayed. But that means that the addresses are offset from those in the bt for the failure process. For #1 0x000000080118d920 in ?? () I end up with: (gdb) x/32i 0x81019b6c0+0xad0-0x880 0x81019b910 : stw r9,0(r18) 0x81019b914 : addis r3,r2,-5 0x81019b918 : addi r3,r3,30120 0x81019b91c : bl 0x81018dfe0 = <00001322.plt_call.getenv> 0x81019b920 : ld r2,40(r1) (The machine code around it all matches around 0x000000080118d920 in the failure context.) The getenv call in the source is the 2nd line of: if (posixly_correct =3D=3D -1 || optreset) posixly_correct =3D (getenv("POSIXLY_CORRECT") !=3D = NULL); For #0 0x000000080118d81c in ?? () I end up with: (gdb) x/32i 0x81019b6c0+0xad0-0x880-0x110 0x81019b800 : bne cr7,0x81019b868 = 0x81019b804 : lwa r5,0(r29) 0x81019b808 : stw r17,0(r18) 0x81019b80c : cmpw cr7,r5,r19 0x81019b810 : bge cr7,0x81019ba60 = 0x81019b814 : rldicr r9,r5,3,60 0x81019b818 : ldx r10,r20,r9 0x81019b81c : lbz r9,0(r10) with the failure being that r10 is zero in that last line above. Again the surrounding code matches. The source code line is reported to be: if (*(place =3D nargv[optind]) !=3D '-' || I got the line number information from breakpoints 3 and 4 below (from the gdb /bin/ls process): (gdb) info br Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000010002360 in main at = /usr/src/bin/ls/ls.c:231 breakpoint already hit 1 time 3 breakpoint keep y 0x000000081019b81c in getopt_internal at = /usr/src/lib/libc/stdlib/getopt_long.c:411 4 breakpoint keep y 0x000000081019b91c in getopt_internal at = /usr/src/lib/libc/stdlib/getopt_long.c:379 Line 379 has the getenv call, matching the machine code showing the call. (I set the breakpoints just as a way of using "info br" to list the information later.) Overall this seems to suggest that: bl <00001322.plt_call.getenv> lead to something odd happening and got to the wrong code. That is all the additional information that I have at this point. I hope it is of some use. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)