From owner-freebsd-toolchain@freebsd.org Sun Jun 9 21:00:34 2019 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 BA14715AB449 for ; Sun, 9 Jun 2019 21:00:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 256D986504 for ; Sun, 9 Jun 2019 21:00:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id D30BC15AB428; Sun, 9 Jun 2019 21:00:33 +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 C076115AB426 for ; Sun, 9 Jun 2019 21:00:33 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (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 "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 519D5864F3 for ; Sun, 9 Jun 2019 21:00:33 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 75BF624EC for ; Sun, 9 Jun 2019 21:00:32 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x59L0Wa9005151 for ; Sun, 9 Jun 2019 21:00:32 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x59L0WGi005150 for toolchain@FreeBSD.org; Sun, 9 Jun 2019 21:00:32 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201906092100.x59L0WGi005150@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: toolchain@FreeBSD.org Subject: Problem reports for toolchain@FreeBSD.org that need special attention Date: Sun, 9 Jun 2019 21:00:32 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Sun, 09 Jun 2019 21:00:34 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 234232 | clang Assertion failed when building the port dev 1 problems total for which you should take action. From owner-freebsd-toolchain@freebsd.org Tue Jun 11 04:05:25 2019 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 0C25115ABC2E for ; Tue, 11 Jun 2019 04:05:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 98CE2725FD for ; Tue, 11 Jun 2019 04:05:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5991215ABC2D; Tue, 11 Jun 2019 04:05:24 +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 45A5B15ABC2C for ; Tue, 11 Jun 2019 04:05:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (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 "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CEE0B725F8 for ; Tue, 11 Jun 2019 04:05:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 133E5133A8 for ; Tue, 11 Jun 2019 04:05:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x5B45MNI003558 for ; Tue, 11 Jun 2019 04:05:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5B45M02003557 for toolchain@FreeBSD.org; Tue, 11 Jun 2019 04:05:22 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 230888] Missing 64 bit atomic functions for i386 (libatomic) Date: Tue, 11 Jun 2019 04:05:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-patch, needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: yuri@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 11 Jun 2019 04:05:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230888 Yuri Victorovich changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yuri@freebsd.org Summary|Missing 64 bit atomic |Missing 64 bit atomic |functions for i386 |functions for i386 | |(libatomic) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Jun 12 04:54:10 2019 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 C591215CED11 for ; Wed, 12 Jun 2019 04:54:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (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 CFBE98D231 for ; Wed, 12 Jun 2019 04:54:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: H5DNLScVM1l5heb0xBT7HURupzJeie6g6OLNXYQIbXu..WCbtPOPqXWKgUFrH5x zsyraFkKd_R8XSEj3HIuMY2gF8cd6U4Qzf57pqTkzkFKZXb403y_JTUBN6L7.YIO7Z7j2WUBTtqs JxWAbMrnOaWnPfqli1NiGMXeqwkREzn1BK6GCS9sK_EzWzQLZtm7dYtlD6OcVCCJqwzJDIOMOZj2 o3svJKjNNEbYCn3joEv1l.GqRtVbfCXoy5DoXqUbzljWss3pNYStuOUUS73sMAheCSQ6TgMW_Bx1 lapP4bmeHNBqKdfyBEJuYKj5y6tGyE.7m3s1aRARO6x3WIRRCMoD1uQwChOwsTkkRTdjetMAhMzs 5ckZOpMyf8aMHEwqCFogC1m9ECYSBCoruSwPU8W4ru3Z3MbSE1T0FpR7HD51jEO0CVkF7acKF04g g_E1BDlweN4S2A.IbaNsHOwMDnM7CMyQaXqbgC5PArn4ax9dosmeJg3x36pE0OKW.liT.4DObvUn 5xblIatTL2C7CgTRgjhGUqC9n9bvARPUiypzdhmtwlooRNbBANHBCNV.QihNMSlDxDbhqgwkJCTQ jJH9d03_ztHA5Ak7ppiE4OEbXnXyzKOEGnnJLrSMYA7MlStiJ0aPX5YdLdDxRuTS0BoxHtlUrs.5 1Xvwr.ShY6HeuVMgV4Oouncavpkk_..xNj9QkB.v3t3wnv7vYXcplfqpwBnzTxXd8o_udJlDJEO6 390QH0IDI_1onyHCoPNWgA2MmUUhjF7hnVZkWThljqOiw4xyd6kHgTcLqz_O__fwuoaBGQ2ZAMyJ hyuIyk9H0HMzwO4Gg79p.HxLgyM916tGdDSxThq92qXfaJcD8Dd.Gd1NaJ8zevOUrZZ34T0f0OBO RjI4RJeuVwUN6n6rohJLCMY8bN.suVyIzgOjbE19wacQtMtT9Zxx2vxqX1EFFtc12r5wMOAeLcXy U1FtqLSuBQ8tsljjbSxPuctv6CpznSF3qvB9h_EV6dARVCENlH8rqqGYhiGwXRilywTfYQ48vuy7 WJuWR7iSzrTboU6WQxTlQW_cGA65YgpcC_KVae5fr.2ClssRmQoKicmyhZlNQ0q0jkcEJg_R.WTG Fncne7.2InJR_.HPZTEuakOQwkESW.Aj.LG7jBu7KjvulBsTOMFTv_2.kyhqcGYnL3ef7YYqp0mV DDjdRkeXeTq8cN_q0WgMiHczdPP44GVEfA7_5V5UIu35Cq1cGCrgn7uKkM3I- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 12 Jun 2019 04:54:00 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp416.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID dce79d6d04f209e2c5bbde054d31f817; Wed, 12 Jun 2019 04:53:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: kern_execve using vm_page_zero_invalid but not vm_page_set_validclean to load /sbin/init ? From: Mark Millard In-Reply-To: <86F7C4C4-2BB6-40F0-B5D3-C80ECB4A97CF@yahoo.com> Date: Tue, 11 Jun 2019 21:53:55 -0700 Cc: Alfredo Dal Ava Junior , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: References: <1464D960-A1D6-404A-BB10-E615E2D14C1D@yahoo.com> <4003198F-C11B-4587-910B-2001DC09F538@yahoo.com> <47E002B7-D4A1-4C4B-BFFD-D926263D895E@yahoo.com> <48148449-93B0-446C-AA28-F211FFAE1A8B@yahoo.com> <86F7C4C4-2BB6-40F0-B5D3-C80ECB4A97CF@yahoo.com> To: FreeBSD Toolchain , FreeBSD Hackers , freeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: CFBE98D231 X-Spamd-Bar: ++++ X-Spamd-Result: default: False [4.34 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.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)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.96)[0.958,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.49)[ip: (5.79), ipnet: 98.137.64.0/21(0.95), asn: 36647(0.76), country: US(-0.06)]; NEURAL_SPAM_MEDIUM(0.50)[0.503,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.90)[0.904,0]; RCVD_IN_DNSWL_NONE(0.00)[146.64.137.98.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] 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: Wed, 12 Jun 2019 04:54:11 -0000 [The garbage after .got up to the page boundary is .comment section strings. The context here is targeting 32-bit powerpc via system-clang-8 and devel/powerpc64-binutils for buildworld and buildkernel . ] On 2019-Jun-11, at 19:55, Mark Millard wrote: > [I have confirmed .sbss not being zero'd out and environ > thereby starting out non-zero (garbage): a > debug.minidump=3D0 style dump.] >=20 >> On 2019-Jun-10, at 16:19, Mark Millard wrote: >>=20 >> . . . (omitted) . . . >=20 > I used debug.minidump=3D0 in /boot/loader.conf for > cusing a dump for the crash and a libkvm modified > enough for my working boot environment to allow me > to examine the the memory-image bytes of such a dump, > with libkvm used via /usr/local/bin/kgdb . (No support > of automatically translating user-space addresses > or other such.) >=20 > For the clang based debug buildworld and debug buildkernel > context with /sbin/init having: >=20 > [16] .got PROGBITS 01956ccc 146ccc 000010 04 WAX = 0 0 4 > [17] .sbss NOBITS 01956cdc 146cdc 0000b0 00 WA = 0 0 4 > [18] .bss NOBITS 01956dc0 146cdc 02ee28 00 WA = 0 0 64 >=20 > I confirmed that .sbss in /sbin/init's address space > is not zeroed (so environ is not assigned by handle_argv ). > I also confirmed that _start was given a good env value > (in %r5) based on where the value was stored on the > stack. It is just that the value was not used. >=20 > The detailed obvious-failure point (crash) can change based > on the garbage in the .sbss and, for the build that I used > this time, that happened in __je_arean_malloc_hard instead > of before _init_tls called _libc_allocate_tls . (I traced > the call chain in the dump.) >=20 >=20 > =46rom what I've seen in the dump there seem to be special > uses of some values (that also have normal uses, of > course): >=20 > 0xfa5005af: as yet invalid page content. > 0x1c000020: as yet unassigned user-space-stack memory for /sbin/init. >=20 > These are the same locations that I previously reported as > showing up in the DSI read trap reports for /sbin/init failing. > The specific build here failed with a different value. >=20 > For reference relative to libkvm: >=20 > # svnlite diff /usr/src/lib/libkvm/ > Index: /usr/src/lib/libkvm/kvm_powerpc.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/lib/libkvm/kvm_powerpc.c (revision 347549) > +++ /usr/src/lib/libkvm/kvm_powerpc.c (working copy) > @@ -211,6 +211,53 @@ > if (be32toh(vm->ph->p_paddr) =3D=3D 0xffffffff) > return ((int)powerpc_va2off(kd, va, ofs)); >=20 > + // HACK in something for what I observe in > + // a debug.minidump=3D0 vmcore.* for 32-bit powerpc > + // > + if ( be32toh(vm->ph->p_vaddr) =3D=3D 0xffffffff > + && be32toh(vm->ph->p_paddr) =3D=3D 0 > + && be16toh(vm->eh->e_phnum) =3D=3D 1 > + ) { > + // Presumes p_memsz is either unsigned > + // 32-bit or is 64-bit, same for va . > + > + if (be32toh(vm->ph->p_memsz) <=3D va) > + return 0; // Like powerpc_va2off > + > + // If ofs was (signed) 32-bit there > + // would be a problem for sufficiently > + // large postive memsz's and va's > + // near the end --because of p_offset > + // and dmphdrsz causing overflow/wrapping > + // for some large va values. > + // Presumes 64-bit ofs for such cases. > + // Also presumes dmphdrsz+p_offset > + // is non-negative so that small > + // non-negative va values have no > + // problems with ofs going negative. > + > + *ofs =3D vm->dmphdrsz > + + be32toh(vm->ph->p_offset) > + + va; > + > + // The normal return value overflows/wraps > + // for p_memsz =3D=3D 0x80000000u when va =3D=3D 0 . > + // Avoid this by depending on calling code's > + // loop for sufficiently large cases. > + // This code presumes p_memsz/2 <=3D MAX_INT . > + // 32-bit powerpc FreeBSD does not allow > + // using more than 2 GiBytes of RAM but > + // does allow using 2 GiBytes on 64-bit > + // hardware. > + // > + if ( (int)be32toh(vm->ph->p_memsz) < 0 > + && va < be32toh(vm->ph->p_memsz)/2 > + ) > + return be32toh(vm->ph->p_memsz)/2; > + > + return be32toh(vm->ph->p_memsz) - va; > + } > + > _kvm_err(kd, kd->program, "Raw corefile not supported"); > return (0); > } > Index: /usr/src/lib/libkvm/kvm_private.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/lib/libkvm/kvm_private.c (revision 347549) > +++ /usr/src/lib/libkvm/kvm_private.c (working copy) > @@ -131,7 +131,9 @@ > { >=20 > return (kd->nlehdr.e_ident[EI_CLASS] =3D=3D class && > - kd->nlehdr.e_type =3D=3D ET_EXEC && > + ( kd->nlehdr.e_type =3D=3D ET_EXEC || > + kd->nlehdr.e_type =3D=3D ET_DYN > + ) && > kd->nlehdr.e_machine =3D=3D machine); > } >=20 >=20 >=20 The following is was is in the .sbss/.bss up to the page boundry (after the .got bytes): (kgdb) x/s 0x2a66cdc 0x2a66cdc: "$FreeBSD: head/lib/csu/powerpc/crt1.c 326219 2017-11-26 = 02:00:33Z pfg $" (kgdb) x/s 0x2a66d24 0x2a66d24: "$FreeBSD: head/lib/csu/common/crtbrand.c 340701 = 2018-11-20 20:59:49Z emaste $" (kgdb) x/s 0x2a66d72 0x2a66d72: "$FreeBSD: head/lib/csu/common/ignore_init.c 340702 = 2018-11-20 21:04:20Z emaste $" (kgdb) x/s 0x2a66dc3 0x2a66dc3: "FreeBSD clang version 8.0.0 (tags/RELEASE_800/final = 356365) (based on LLVM 8.0.0)" (kgdb) x/s 0x2a66e15 0x2a66e15: "$FreeBSD: head/lib/csu/powerpc/crti.S 217399 2011-01-14 = 11:34:58Z kib $" (kgdb) x/s 0x2a66e5d 0x2a66e5d: "$FreeBSD: head/sbin/mount/getmntopts.c 326025 = 2017-11-20 19:49:47Z pfg $" (kgdb) x/s 0x2a66ea6 0x2a66ea6: "$FreeBSD: head/lib/libutil/login_tty.c 334106 = 2018-05-23 17:02:12Z jhb $" (kgdb) x/s 0x2a66eef 0x2a66eef: "$FreeBSD: head/lib/libutil/login_class.c 296723 = 2016-03-12 14:54:34Z kib $" (kgdb) x/s 0x2a66f83 0x2a66f83: "$FreeBSD: head/lib/libutil/_secure_path.c 139012 = 2004-12-18 12:31:12Z ru $" (kgdb) x/s 0x2a66fce 0x2a66fce: "$FreeBSD: head/lib/libcrypt/crypt.c 326219 2017-11 (I truncated that last to avoid the 0xfa5005af's on the next page in RAM.) Compare ( from readelf /sbin/init ): String dump of section '.comment': [ 0] $FreeBSD: head/lib/csu/powerpc/crt1.c 326219 2017-11-26 = 02:00:33Z pfg $ [ 48] $FreeBSD: head/lib/csu/common/crtbrand.c 340701 2018-11-20 = 20:59:49Z emaste $ [ 96] $FreeBSD: head/lib/csu/common/ignore_init.c 340702 = 2018-11-20 21:04:20Z emaste $ [ e7] FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) = (based on LLVM 8.0.0) [ 139] $FreeBSD: head/lib/csu/powerpc/crti.S 217399 2011-01-14 = 11:34:58Z kib $ [ 181] $FreeBSD: head/sbin/mount/getmntopts.c 326025 2017-11-20 = 19:49:47Z pfg $ [ 1ca] $FreeBSD: head/lib/libutil/login_tty.c 334106 2018-05-23 = 17:02:12Z jhb $ [ 213] $FreeBSD: head/lib/libutil/login_class.c 296723 2016-03-12 = 14:54:34Z kib $ [ 25e] $FreeBSD: head/lib/libutil/login_cap.c 317265 2017-04-21 = 19:27:33Z pfg $ [ 2a7] $FreeBSD: head/lib/libutil/_secure_path.c 139012 2004-12-18 = 12:31:12Z ru $ [ 2f2] $FreeBSD: head/lib/libcrypt/crypt.c 326219 2017-11-26 = 02:00:33Z pfg $ . . . Note: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg = Align LOAD 0x000000 0x01800000 0x01800000 0x140ad4 0x140ad4 R E = 0x10000 LOAD 0x140ae0 0x01950ae0 0x01950ae0 0x061fc 0x35108 RWE = 0x10000 NOTE 0x0000d4 0x018000d4 0x018000d4 0x00048 0x00048 R 0x4 TLS 0x140ae0 0x01950ae0 0x01950ae0 0x00b10 0x00b1d R 0x10 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 Section to Segment mapping: Segment Sections... 00 .note.tag .init .text .fini .rodata .eh_frame=20 01 .tdata .tbss .init_array .fini_array .ctors .dtors .jcr = .data.rel.ro .data .got .sbss .bss=20 02 .note.tag=20 03 .tdata .tbss=20 04 =20 There are 24 section headers, starting at offset 0x16cec8: Section Headers: [Nr] Name Type Addr Off Size ES Flg = Lk Inf Al . . . [16] .got PROGBITS 01956ccc 146ccc 000010 04 WAX = 0 0 4 [17] .sbss NOBITS 01956cdc 146cdc 0000b0 00 WA = 0 0 4 [18] .bss NOBITS 01956dc0 146cdc 02ee28 00 WA = 0 0 64 [19] .comment PROGBITS 00000000 146cdc 0073d4 01 MS = 0 0 1 It looks like material after the .got is being copied, spanning the in-file-empty .sbss and .bss sections and implicitly initializing (the first part of) those sections. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Wed Jun 12 09:06:47 2019 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 CF5B715AE9B4 for ; Wed, 12 Jun 2019 09:06:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 692F16D5A5 for ; Wed, 12 Jun 2019 09:06:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2642A15AE9B0; Wed, 12 Jun 2019 09:06:47 +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 1395415AE9AF for ; Wed, 12 Jun 2019 09:06:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (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 "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A31986D5A2 for ; Wed, 12 Jun 2019 09:06:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id E226C2BE9 for ; Wed, 12 Jun 2019 09:06:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x5C96jul063145 for ; Wed, 12 Jun 2019 09:06:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5C96jJb063137 for toolchain@FreeBSD.org; Wed, 12 Jun 2019 09:06:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 238514] Adding -flto into compilation/link lines causes the error: /usr/bin/ld: unrecognized option '-plugin' Date: Wed, 12 Jun 2019 09:06:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Wed, 12 Jun 2019 09:06:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238514 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |toolchain@FreeBSD.org Summary|[toolchain] Adding -flto |Adding -flto into |into compilation/link lines |compilation/link lines |causes the error: |causes the error: |/usr/bin/ld: unrecognized |/usr/bin/ld: unrecognized |option '-plugin' |option '-plugin' --- Comment #1 from Mark Linimon --- Assign to toolchain@, and thus, remove the now-redundant tag. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Jun 12 10:54:46 2019 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 414AB15B154D for ; Wed, 12 Jun 2019 10:54:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 C79AE70A15 for ; Wed, 12 Jun 2019 10:54:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 82D6315B154C; Wed, 12 Jun 2019 10:54:45 +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 6EBDB15B154B for ; Wed, 12 Jun 2019 10:54:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (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 "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F214B70A11 for ; Wed, 12 Jun 2019 10:54:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 1E07B3E01 for ; Wed, 12 Jun 2019 10:54:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x5CAsh6P067999 for ; Wed, 12 Jun 2019 10:54:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5CAshfA067998 for toolchain@FreeBSD.org; Wed, 12 Jun 2019 10:54:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 238514] Adding -flto into compilation/link lines causes the error: /usr/bin/ld: unrecognized option '-plugin' Date: Wed, 12 Jun 2019 10:54:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Wed, 12 Jun 2019 10:54:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238514 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dim@FreeBSD.org --- Comment #2 from Dimitry Andric --- This is because 11.2 and 12.0 i386 are still on BFD ld 2.17.50, which neith= er supports LTO, nor plugins. It's probably best to leave off -flto for these platforms, otherwise use lld or the binutils port. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Jun 12 14:35:13 2019 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 AFF0C15B855A for ; Wed, 12 Jun 2019 14:35:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 4101077DEE for ; Wed, 12 Jun 2019 14:35:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 020E415B8559; Wed, 12 Jun 2019 14:35:13 +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 E35B815B8557 for ; Wed, 12 Jun 2019 14:35:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (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 "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B40C77DEA for ; Wed, 12 Jun 2019 14:35:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 9EB665D99 for ; Wed, 12 Jun 2019 14:35:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x5CEZBMv050183 for ; Wed, 12 Jun 2019 14:35:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5CEZBq1050182 for toolchain@FreeBSD.org; Wed, 12 Jun 2019 14:35:11 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 238514] Adding -flto into compilation/link lines causes the error: /usr/bin/ld: unrecognized option '-plugin' Date: Wed, 12 Jun 2019 14:35:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cem@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: version Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Wed, 12 Jun 2019 14:35:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238514 Conrad Meyer changed: What |Removed |Added ---------------------------------------------------------------------------- Version|CURRENT |12.0-RELEASE --- Comment #3 from Conrad Meyer --- [Not CURRENT] --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Jun 12 19:13:11 2019 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 D0B7A15BF86F for ; Wed, 12 Jun 2019 19:13:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-2.consmr.mail.bf2.yahoo.com (sonic308-2.consmr.mail.bf2.yahoo.com [74.6.130.41]) (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 CA52789E9E for ; Wed, 12 Jun 2019 19:13:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 9KsIYDQVM1lTOuaOOgcDyV586bXcOdOjtwHYpRu97YJa_ZXT1wkBNex9YGPaqVX D3FRVvHL9SBLpE5GOSXbv3S20URAIUDkHZtHWYAOYuM8EEvBV47.zyHnVaqnx1a7rPFYwDwAEMXp pg5vpieQaBlepNYg8oiFbBOGm8MjZD17pL2mMN4wjgksJhafKiwVKMHTeAfp2gfpEdpPTIcGyCip SeuPfuOHD5HGItm6nonxRSho_UUMdPJgGmNnug6UhKXpcvZxuODJdYp7tM_JMlPl3osfX8uW71um Clx3uF38cBOt.4PTMiauu.a4OYoxmwbQUgkfuTea5ShTY2H3USwlnUVk6xOBuiyfmyLgTq9f3cND eg3M22dx.6ejaVccCNfFiVPi4pMuq2c.OAJPU5HXZHu5VmUyBxtUskz742AhnXxADnqmx03MJAjJ pEObTL_fddwumVcbp0dLh4ME.3QXGSESOmTiwtJOFwWEWWJCE.7nWIh1iRXj4W5W3IIC6r7SliYM NLm4Pb2ELGhnGNTI4W8mdGdSqG5fpRujH7_UhZkbZuiuVHuAdFq1de3A3XUNHLeRo2yAD_n23f1A _5shw35Nx2qJPW3Gg96WBCgeD.gmjV4grQEnPiR57pxx3eb.FJi2DPigXVwCAfETiWjydZ9D9iMt AEdAWvLfkRqgCN2s2nPmWcrrJ8EjyfIG.dMX9MzVqKK7SedaqglYFKZPmUCJi8EtITKjyjy9YURo j3zK7nf_A..W6AsSwAE._7dQxTdRiYx6zU7UPcvBYe5Ojjelb0foejhbXVvoFDSja2b_kWWOnqa0 RNJ4q5Drr.cjwDDRtee_dqtl0_MXk_V8MsxuRzw0UzRKck6wLupkXHQMOdkWbG0dk4g9psroHoSL 16CkhmPWXNV_Pw6RUI_YHquMbbx4FCHSAvG579CuNhEcose1QM8Z.GAU.whwPjkLv_mculFhd43j sfv.zTYVZOIPa6_AFMpiJe2S2Umc6EBWxDCYZHGlptVAPjJ8UuYj8fuGkGn6u3.KpobN8rlgHlWR tQr37LZ__ZppyCNS57FU18SnugCfa7uwWjqYScV2b1ubbjWr.HfFK2lrXI9CHhg1SUEi.TYQi87d QbauPib_ZYUY31SOmhMNFio5QtG6dckUEwHnzsrx1KflcOkdscssJyGJMQMSKTc1LcaPSJdK5KHO u154H2XgpNH6OAFtCDyk9snOFq7ogNE41ocCW4WcL77Y2lApMKH0Q0pI9jTPIeA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Wed, 12 Jun 2019 19:13:03 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.115]) ([67.170.167.181]) by smtp415.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 61b8c36a736c57820c4825611c6738d1; Wed, 12 Jun 2019 19:13:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: kern_execve using vm_page_zero_invalid but not vm_page_set_validclean to load /sbin/init ? From: Mark Millard In-Reply-To: Date: Wed, 12 Jun 2019 12:12:57 -0700 Cc: Alfredo Dal Ava Junior , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: References: <1464D960-A1D6-404A-BB10-E615E2D14C1D@yahoo.com> <4003198F-C11B-4587-910B-2001DC09F538@yahoo.com> <47E002B7-D4A1-4C4B-BFFD-D926263D895E@yahoo.com> <48148449-93B0-446C-AA28-F211FFAE1A8B@yahoo.com> <86F7C4C4-2BB6-40F0-B5D3-C80ECB4A97CF@yahoo.com> To: FreeBSD Toolchain , FreeBSD Hackers , freeBSD PowerPC ML , Conrad Meyer X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: CA52789E9E X-Spamd-Bar: +++ X-Spamd-Result: default: False [3.35 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.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)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.09)[0.086,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_MEDIUM(0.29)[0.293,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.96)[0.961,0]; RCVD_IN_DNSWL_NONE(0.00)[41.130.6.74.list.dnswl.org : 127.0.5.0]; IP_SCORE(1.52)[ip: (4.91), ipnet: 74.6.128.0/21(1.52), asn: 26101(1.21), country: US(-0.06)]; RWL_MAILSPIKE_POSSIBLE(0.00)[41.130.6.74.rep.mailspike.net : 127.0.0.17] 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: Wed, 12 Jun 2019 19:13:11 -0000 [Looks to me like the ->valid mask only is used for the last page of the /sbin/init file, not based on the size and alignment of the data requested for the PT_LOAD.] On 2019-Jun-11, at 21:53, Mark Millard wrote: > [The garbage after .got up to the page boundary is > .comment section strings. The context here is > targeting 32-bit powerpc via system-clang-8 and > devel/powerpc64-binutils for buildworld and > buildkernel . ] >=20 > On 2019-Jun-11, at 19:55, Mark Millard wrote: >=20 >> [I have confirmed .sbss not being zero'd out and environ >> thereby starting out non-zero (garbage): a >> debug.minidump=3D0 style dump.] >>=20 >>> On 2019-Jun-10, at 16:19, Mark Millard wrote: >>>=20 >>> . . . (omitted) . . . >>=20 >> I used debug.minidump=3D0 in /boot/loader.conf for >> cusing a dump for the crash and a libkvm modified >> enough for my working boot environment to allow me >> to examine the the memory-image bytes of such a dump, >> with libkvm used via /usr/local/bin/kgdb . (No support >> of automatically translating user-space addresses >> or other such.) >>=20 >> For the clang based debug buildworld and debug buildkernel >> context with /sbin/init having: >>=20 >> [16] .got PROGBITS 01956ccc 146ccc 000010 04 WAX = 0 0 4 >> [17] .sbss NOBITS 01956cdc 146cdc 0000b0 00 WA = 0 0 4 >> [18] .bss NOBITS 01956dc0 146cdc 02ee28 00 WA = 0 0 64 >>=20 >> I confirmed that .sbss in /sbin/init's address space >> is not zeroed (so environ is not assigned by handle_argv ). >> I also confirmed that _start was given a good env value >> (in %r5) based on where the value was stored on the >> stack. It is just that the value was not used. >>=20 >> The detailed obvious-failure point (crash) can change based >> on the garbage in the .sbss and, for the build that I used >> this time, that happened in __je_arean_malloc_hard instead >> of before _init_tls called _libc_allocate_tls . (I traced >> the call chain in the dump.) >>=20 >>=20 >> =46rom what I've seen in the dump there seem to be special >> uses of some values (that also have normal uses, of >> course): >>=20 >> 0xfa5005af: as yet invalid page content. >> 0x1c000020: as yet unassigned user-space-stack memory for /sbin/init. >>=20 >> These are the same locations that I previously reported as >> showing up in the DSI read trap reports for /sbin/init failing. >> The specific build here failed with a different value. >>=20 >> For reference relative to libkvm: >>=20 >> # svnlite diff /usr/src/lib/libkvm/ >> Index: /usr/src/lib/libkvm/kvm_powerpc.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/lib/libkvm/kvm_powerpc.c (revision 347549) >> +++ /usr/src/lib/libkvm/kvm_powerpc.c (working copy) >> @@ -211,6 +211,53 @@ >> if (be32toh(vm->ph->p_paddr) =3D=3D 0xffffffff) >> return ((int)powerpc_va2off(kd, va, ofs)); >>=20 >> + // HACK in something for what I observe in >> + // a debug.minidump=3D0 vmcore.* for 32-bit powerpc >> + // >> + if ( be32toh(vm->ph->p_vaddr) =3D=3D 0xffffffff >> + && be32toh(vm->ph->p_paddr) =3D=3D 0 >> + && be16toh(vm->eh->e_phnum) =3D=3D 1 >> + ) { >> + // Presumes p_memsz is either unsigned >> + // 32-bit or is 64-bit, same for va . >> + >> + if (be32toh(vm->ph->p_memsz) <=3D va) >> + return 0; // Like powerpc_va2off >> + >> + // If ofs was (signed) 32-bit there >> + // would be a problem for sufficiently >> + // large postive memsz's and va's >> + // near the end --because of p_offset >> + // and dmphdrsz causing overflow/wrapping >> + // for some large va values. >> + // Presumes 64-bit ofs for such cases. >> + // Also presumes dmphdrsz+p_offset >> + // is non-negative so that small >> + // non-negative va values have no >> + // problems with ofs going negative. >> + >> + *ofs =3D vm->dmphdrsz >> + + be32toh(vm->ph->p_offset) >> + + va; >> + >> + // The normal return value overflows/wraps >> + // for p_memsz =3D=3D 0x80000000u when va =3D=3D 0 . >> + // Avoid this by depending on calling code's >> + // loop for sufficiently large cases. >> + // This code presumes p_memsz/2 <=3D MAX_INT . >> + // 32-bit powerpc FreeBSD does not allow >> + // using more than 2 GiBytes of RAM but >> + // does allow using 2 GiBytes on 64-bit >> + // hardware. >> + // >> + if ( (int)be32toh(vm->ph->p_memsz) < 0 >> + && va < be32toh(vm->ph->p_memsz)/2 >> + ) >> + return be32toh(vm->ph->p_memsz)/2; >> + >> + return be32toh(vm->ph->p_memsz) - va; >> + } >> + >> _kvm_err(kd, kd->program, "Raw corefile not supported"); >> return (0); >> } >> Index: /usr/src/lib/libkvm/kvm_private.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/lib/libkvm/kvm_private.c (revision 347549) >> +++ /usr/src/lib/libkvm/kvm_private.c (working copy) >> @@ -131,7 +131,9 @@ >> { >>=20 >> return (kd->nlehdr.e_ident[EI_CLASS] =3D=3D class && >> - kd->nlehdr.e_type =3D=3D ET_EXEC && >> + ( kd->nlehdr.e_type =3D=3D ET_EXEC || >> + kd->nlehdr.e_type =3D=3D ET_DYN >> + ) && >> kd->nlehdr.e_machine =3D=3D machine); >> } >>=20 >>=20 >>=20 >=20 > The following is was is in the .sbss/.bss up to the page > boundry (after the .got bytes): >=20 > (kgdb) x/s 0x2a66cdc > 0x2a66cdc: "$FreeBSD: head/lib/csu/powerpc/crt1.c 326219 2017-11-26 = 02:00:33Z pfg $" >=20 > (kgdb) x/s 0x2a66d24 > 0x2a66d24: "$FreeBSD: head/lib/csu/common/crtbrand.c 340701 = 2018-11-20 20:59:49Z emaste $" >=20 > (kgdb) x/s 0x2a66d72 > 0x2a66d72: "$FreeBSD: head/lib/csu/common/ignore_init.c 340702 = 2018-11-20 21:04:20Z emaste $" >=20 > (kgdb) x/s 0x2a66dc3 > 0x2a66dc3: "FreeBSD clang version 8.0.0 (tags/RELEASE_800/final = 356365) (based on LLVM 8.0.0)" >=20 > (kgdb) x/s 0x2a66e15 > 0x2a66e15: "$FreeBSD: head/lib/csu/powerpc/crti.S 217399 2011-01-14 = 11:34:58Z kib $" >=20 > (kgdb) x/s 0x2a66e5d > 0x2a66e5d: "$FreeBSD: head/sbin/mount/getmntopts.c 326025 = 2017-11-20 19:49:47Z pfg $" >=20 > (kgdb) x/s 0x2a66ea6 > 0x2a66ea6: "$FreeBSD: head/lib/libutil/login_tty.c 334106 = 2018-05-23 17:02:12Z jhb $" >=20 > (kgdb) x/s 0x2a66eef > 0x2a66eef: "$FreeBSD: head/lib/libutil/login_class.c 296723 = 2016-03-12 14:54:34Z kib $" >=20 > (kgdb) x/s 0x2a66f83 > 0x2a66f83: "$FreeBSD: head/lib/libutil/_secure_path.c 139012 = 2004-12-18 12:31:12Z ru $" >=20 > (kgdb) x/s 0x2a66fce > 0x2a66fce: "$FreeBSD: head/lib/libcrypt/crypt.c 326219 2017-11 >=20 > (I truncated that last to avoid the 0xfa5005af's on the next page > in RAM.) >=20 > Compare ( from readelf /sbin/init ): >=20 > String dump of section '.comment': > [ 0] $FreeBSD: head/lib/csu/powerpc/crt1.c 326219 2017-11-26 = 02:00:33Z pfg $ > [ 48] $FreeBSD: head/lib/csu/common/crtbrand.c 340701 2018-11-20 = 20:59:49Z emaste $ > [ 96] $FreeBSD: head/lib/csu/common/ignore_init.c 340702 = 2018-11-20 21:04:20Z emaste $ > [ e7] FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) = (based on LLVM 8.0.0) > [ 139] $FreeBSD: head/lib/csu/powerpc/crti.S 217399 2011-01-14 = 11:34:58Z kib $ > [ 181] $FreeBSD: head/sbin/mount/getmntopts.c 326025 2017-11-20 = 19:49:47Z pfg $ > [ 1ca] $FreeBSD: head/lib/libutil/login_tty.c 334106 2018-05-23 = 17:02:12Z jhb $ > [ 213] $FreeBSD: head/lib/libutil/login_class.c 296723 2016-03-12 = 14:54:34Z kib $ > [ 25e] $FreeBSD: head/lib/libutil/login_cap.c 317265 2017-04-21 = 19:27:33Z pfg $ > [ 2a7] $FreeBSD: head/lib/libutil/_secure_path.c 139012 2004-12-18 = 12:31:12Z ru $ > [ 2f2] $FreeBSD: head/lib/libcrypt/crypt.c 326219 2017-11-26 = 02:00:33Z pfg $ > . . . >=20 > Note: >=20 > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg = Align > LOAD 0x000000 0x01800000 0x01800000 0x140ad4 0x140ad4 R E = 0x10000 > LOAD 0x140ae0 0x01950ae0 0x01950ae0 0x061fc 0x35108 RWE = 0x10000 > NOTE 0x0000d4 0x018000d4 0x018000d4 0x00048 0x00048 R 0x4 > TLS 0x140ae0 0x01950ae0 0x01950ae0 0x00b10 0x00b1d R = 0x10 > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW = 0x10 >=20 > Section to Segment mapping: > Segment Sections... > 00 .note.tag .init .text .fini .rodata .eh_frame=20 > 01 .tdata .tbss .init_array .fini_array .ctors .dtors .jcr = .data.rel.ro .data .got .sbss .bss=20 > 02 .note.tag=20 > 03 .tdata .tbss=20 > 04 =20 > There are 24 section headers, starting at offset 0x16cec8: >=20 > Section Headers: > [Nr] Name Type Addr Off Size ES Flg = Lk Inf Al > . . . > [16] .got PROGBITS 01956ccc 146ccc 000010 04 WAX = 0 0 4 > [17] .sbss NOBITS 01956cdc 146cdc 0000b0 00 WA = 0 0 4 > [18] .bss NOBITS 01956dc0 146cdc 02ee28 00 WA = 0 0 64 > [19] .comment PROGBITS 00000000 146cdc 0073d4 01 MS = 0 0 1 >=20 > It looks like material after the .got is being copied, > spanning the in-file-empty .sbss and .bss sections and > implicitly initializing (the first part of) those > sections. The ->valid assignments appears to trace to code like: /* * The last page has valid blocks. Invalid part can only * exist at the end of file, and the page is made fully valid * by zeroing in vm_pager_get_pages(). */ if (m[count - 1]->valid !=3D 0 && --count =3D=3D 0) { if (iodone !=3D NULL) iodone(arg, m, 1, 0); return (VM_PAGER_OK); } independent of if the requested data does not span into the last page but does not span to the end of a page. So it appears that the use of: QUOTE vm_imgact_map_page uses vm_imgact_hold_page. vm_imgact_hold_page uses vm_pager_get_pages. vm_pager_get_pages uses vm_page_zero_invalid to "Zero out partially filled data" END QUOTE simply does not do the right thing for .sbss or .bss handling. The m->valid related code for zeroing is basically irrelevant to .sbss and .bss. Note that the below code requires a m->valid bit to be asserted in order to do any pmap_zero_page_area operations. Thus it does not zero out pages that are completely invalid either. This explains why I see 0xfa5005af on the full pages in the .sbss/.bss area for debug builds: nothing is zeroing the full pages either. void vm_page_zero_invalid(vm_page_t m, boolean_t setvalid) { int b; int i; VM_OBJECT_ASSERT_WLOCKED(m->object); /* * Scan the valid bits looking for invalid sections that * must be zeroed. Invalid sub-DEV_BSIZE'd areas ( where the * valid bit may be set ) have already been zeroed by * vm_page_set_validclean(). */ for (b =3D i =3D 0; i <=3D PAGE_SIZE / DEV_BSIZE; ++i) { if (i =3D=3D (PAGE_SIZE / DEV_BSIZE) || (m->valid & ((vm_page_bits_t)1 << i))) { if (i > b) { pmap_zero_page_area(m, b << DEV_BSHIFT, (i - b) << = DEV_BSHIFT); } b =3D i + 1; } } /* * setvalid is TRUE when we can safely set the zero'd areas * as being valid. We can do this if there are no cache = consistancy * issues. e.g. it is ok to do with UFS, but not ok to do with = NFS. */ if (setvalid) m->valid =3D VM_PAGE_BITS_ALL; } This code simply does not do the right thing for .sbss and .bss handling. __start in /sbin/init (for example) expects .sbss and .bss to have already been initialized to zero (and possibly further adjusted after that for something like environ). So far I find nothing to cover that. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)