From owner-freebsd-toolchain@freebsd.org Tue Nov 6 02:52:12 2018 Return-Path: Delivered-To: freebsd-toolchain@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 6E360112BDF2 for ; Tue, 6 Nov 2018 02:52:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DD4F58729B for ; Tue, 6 Nov 2018 02:52:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id A279F112BDEE; Tue, 6 Nov 2018 02:52:11 +0000 (UTC) Delivered-To: toolchain@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 7F9E2112BDEC; Tue, 6 Nov 2018 02:52:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE3D787294; Tue, 6 Nov 2018 02:52:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id wA62q0M2072867 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Nov 2018 04:52:03 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua wA62q0M2072867 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id wA62pxXi072866; Tue, 6 Nov 2018 04:51:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 6 Nov 2018 04:51:59 +0200 From: Konstantin Belousov To: Charlie Li Cc: Brooks Davis , svn-src-head@freebsd.org, toolchain@freebsd.org, current@freebsd.org Subject: Re: svn commit: r339898 - head/lib/libc/amd64/sys Message-ID: <20181106025159.GU5335@kib.kiev.ua> References: <201810300011.w9U0BUui038857@repo.freebsd.org> <20181101160406.GA60233__23941.7825396687$1541088368$gmane$org@spindle.one-eyed-alien.net> <20181103152936.GQ5335@kib.kiev.ua> <20181103234551.GX5335@kib.kiev.ua> <4907b3f9-d1c6-4368-5597-ce3d6be19461@vishwin.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4907b3f9-d1c6-4368-5597-ce3d6be19461@vishwin.info> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: DD4F58729B X-Spamd-Result: default: False [-6.11 / 200.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_FIVE(0.00)[6]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_FIVE(0.00)[5]; IP_SCORE(-3.10)[ip: (-9.26), ipnet: 2001:1900:2254::/48(-3.57), asn: 10310(-2.58), country: US(-0.07)]; RCVD_IN_DNSWL_MED(-0.20)[5.0.0.0.0.5.0.0.0.0.0.0.0.0.0.0.a.6.0.2.4.5.2.2.0.0.9.1.1.0.0.2.list.dnswl.org : 127.0.9.2]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.90)[-0.904,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:10310, ipnet:2001:1900:2254::/48, country:US]; FORGED_RECIPIENTS(0.00)[ml@vishwin.info ..,freebsd-toolchain@freebsd.org]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 02:52:12 -0000 On Mon, Nov 05, 2018 at 09:10:13PM -0500, Charlie Li wrote: > On 03/11/2018 19:45, Konstantin Belousov wrote: > > Or rather, it is a middle of the valid instruction. > > Next frame looks like it is process_irelocs(), if trusting the line > > numbers. So most likely it is something related to calling wrong > > relocator function, if anything. > > > > Perhaps you could try to trace the things manually, doing > > single-stepping of the startup code in debugger. There should be very > > modest amount of the irelocs, perhaps only one, and see where things go > > off the way. > > > After a few more complete buildworlds, including one with all > bootstrapping enabled, this doesn't look compiler-specific. Static > binaries built with the in-tree base LLVM (6.0.1) also crash. For you, but not for me. > > I stepped through bmake with base lldb, comparing the working copy in my > system from circa r339990 with r340173 built with bootstrapped > toolchain. Only the differing parts are shown for conciseness. > > Circa r339990: > Process 82271 stopped > * thread #1, name = 'make', stop reason = step over > frame #0: 0x000000000024ab06 make`_init_tls at tls.c:471 > 468 } > 469 tls = _rtld_allocate_tls(NULL, TLS_TCB_SIZE, TLS_TCB_ALIGN); > 470 > -> 471 _set_tp(tls); > 472 #endif > 473 } > (lldb) n > Process 82271 stopped > * thread #1, name = 'make', stop reason = step over > frame #0: 0x0000000000255e60 make`_set_tp(tp=0x00000008002f7830) at > _set_tp.c:38 > 35 > 36 void > 37 _set_tp(void *tp) > -> 38 { > 39 > 40 amd64_set_fsbase(tp); > 41 } > (lldb) s > Process 82271 stopped > * thread #1, name = 'make', stop reason = step in > frame #0: 0x0000000000255e64 make`_set_tp(tp=0x00000008002f7830) at > _set_tp.c:40 > 37 _set_tp(void *tp) > 38 { > 39 > -> 40 amd64_set_fsbase(tp); > 41 } > (lldb) s > Process 82271 stopped > * thread #1, name = 'make', stop reason = step in > frame #0: 0x0000000000256580 > make`amd64_set_fsbase(addr=0x00000008002f7830) at amd64_set_fsbase.c:43 > 40 #include > 41 #include > 42 #include > -> 43 #include "libc_private.h" > 44 > 45 static int > 46 amd64_set_fsbase_cpu(void *addr) > (lldb) > > r340173: > Process 22663 stopped > * thread #1, name = 'make', stop reason = step over > frame #0: 0x0000000000247c96 make`_init_tls at tls.c:471 > 468 } > 469 tls = _rtld_allocate_tls(NULL, TLS_TCB_SIZE, TLS_TCB_ALIGN); > 470 > -> 471 _set_tp(tls); > 472 #endif > 473 } > (lldb) n > Process 22663 stopped > * thread #1, name = 'make', stop reason = step over > frame #0: 0x0000000000252eb0 make`_set_tp(tp=0x00000008002ed830) at > _set_tp.c:38 > 35 > 36 void > 37 _set_tp(void *tp) > -> 38 { > 39 > 40 amd64_set_fsbase(tp); > 41 } > (lldb) s > Process 22663 stopped > * thread #1, name = 'make', stop reason = step in > frame #0: 0x0000000000252eb4 make`_set_tp(tp=0x00000008002ed830) at > _set_tp.c:40 > 37 _set_tp(void *tp) > 38 { > 39 > -> 40 amd64_set_fsbase(tp); > 41 } > (lldb) s > Process 22663 stopped > * thread #1, name = 'make', stop reason = step in > frame #0: 0x0000000000252eb5 make`_set_tp(tp=0x00000008002ed830) at > _set_tp.c:40 > 37 _set_tp(void *tp) > 38 { > 39 > -> 40 amd64_set_fsbase(tp); > 41 } > (lldb) s > Process 22663 stopped > * thread #1, name = 'make', stop reason = step in > frame #0: 0x00000000002ebdb0 make > -> 0x2ebdb0: movq 0x3ce9(%rip), %r11 > 0x2ebdb7: callq 0x2ebda0 ; _fini > 0x2ebdbc: jmp 0x2ebd92 ; _init + 6 > 0x2ebdc1: pushq $0x0 > (lldb) n > Process 22663 stopped > * thread #1, name = 'make', stop reason = instruction step over > frame #0: 0x00000000002ebdb7 make > -> 0x2ebdb7: callq 0x2ebda0 ; _fini I guess this is where things go off for you, but I may be wrong. After ifuncification, 'amd64_set_fsbase()' line should be represented by the asm as either call and the place in plt is just jmp *(rip-based offset to GOT)(%rip) In fact the call to amd64_set_fsbase() in the tail-call position, so the first call is jmp. For me, everything works. If for you it does not you should look at the instructions and see which values went off. You completely omitted that details from your trace, so I cannot even guess which part was corrupted. Again, for me it works with the in-tree toolchain, so I am quite sure that you have trouble with the toolchain.