From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 1AD4B3857818 for ; Tue, 22 Feb 2022 17:17:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1AD4B3857818 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org Received: by smtp.gentoo.org (Postfix, from userid 559) id AE498343775; Tue, 22 Feb 2022 17:17:39 +0000 (UTC) Date: Tue, 22 Feb 2022 12:17:40 -0500 From: Mike Frysinger To: Jon Turney Cc: "newlib@sourceware.org" Subject: Re: [PATCH v2] newlib: libm: workaround ar duplicate member behavior Message-ID: Mail-Followup-To: Jon Turney , "newlib@sourceware.org" References: <20220221204327.2945-1-vapier@gentoo.org> <20220222002114.10214-1-vapier@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Vsx21O/XFn/qaAE0" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2022 17:17:42 -0000 --Vsx21O/XFn/qaAE0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 22 Feb 2022 12:34, Jon Turney wrote: > On 22/02/2022 11:31, Corinna Vinschen wrote: > > On Feb 21 19:21, Mike Frysinger wrote: > >> GNU ar has undocumented behavior where it doesn't dedupe its inputs if > >> they're all on the same command line, so we have to dedupe ourselves. > >> --- > >> v2 > >> - use awk to dedupe the object list >=20 > I think this could still at least use a comment about how the ordering=20 > of the inputs relates to which duplicate object are dropped and which=20 > are kept. i had updated the comment locally already and just hadn't posted it: ## GNU ar has undocumented behavior when specifying the same name multiple = times ## in a single invocation, so we have to dedupe ourselves. The algorithm h= ere: ## - Generates the set of unique objects based on the basename. ## - Favors objects later in the list (since machine objects come last). ## - Outputs object list in same order as input for reproducibility. > (I'm assuming cpu-specific ones are meant to be kept in preference to=20 > generic routines, but how does this achieve that?) >=20 > > This seems to work. > >=20 > > However, what do we have to do in future to make sure the order is > > always correct? i've documented this in 3 places, so think it's fine. (1) libc/Makefile.inc & (2) libm/Makefile.inc both have: ## The order of includes is important for two reasons: ## * The integrated documentation (chapter ordering). ## * Object overridding -- machine dir must come last. ## Do not change the order without considering the doc impact. (3) in the heavily rewritten build documentation i sent out [1]. it's pending review from folks, so hasn't been merged yet. > > And the heritic question: Wouldn't it be safer to keep the old > > per-subdir lib.a logic? i think this is a false dichotomy. the lib.a logic has the same problem, albeit it was never documented: if the order of SUBDIRS isn't maintained, then the machine overrides do not work correctly. if the order of the lib.a unpacking was not done correctly, then the machine overrides do not work correctly. the fact that it's been "stable for so long" isn't due to the code being written well (no offense), it's because it's been so dense & undocumented that no one has wanted to touch it with a 3m pole :P. > Considering the problem in the next larger context: why are we doing=20 > this at all? >=20 > Is this just so the generic fenv routines are chewed on as they contain= =20 > the doc markup? In which case it would be simpler to do that explicitly. >=20 > If it's so that a cpu- specific fenv doesn't need to provide all the=20 > objects, well, that could be done explicitly as well, I think? assuming you're asking about the machine-override logic specifically and not "why am i changing the build system at all", then the current newlib design supports more than fenv. fortunately, i believe i already wrote up all the docs you want :). please give it a look and see if i missed anything. [1] https://sourceware.org/pipermail/newlib/2022/019275.html -mike --Vsx21O/XFn/qaAE0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmIVGrQACgkQQWM7n+g3 9YG5QA//Q0+fTsa5wskZkACwDuhf80WPJ5wyUorLkBNHgoHgASVjniuLzTkHhkXh ux2DGXDylHFj8oCQeK+J7fDwpxjbOI/5LJ1hkxECKuzCyOonzuQGEWOsvIETX3RD xfhISAatZHs5edywgvQw+A5uddMJA9srvvXVstAzU1hWHb2bmsAL49hVgY9unA3d R7a4FMy6KIcdYMmg1kLabcxWwawYV6/+UtteGEzd7SEkBtYRPmSe/nurIuluxSEz 4DKstePpAShZ5turOABAELUgoMdgXtNhUz9Q+NLVqbg2iIk/L1odqp2lr53vutAL TgfTqoT7QCLYDGlF0GBqa6pqpQuFYKYNFE/0DgvVRM+HMGlmsj2PbuyiXASqjPbQ uK9HsryAKZXDC+Fyx5J5MqrqBPCIn+fyJWyyT+454NAhTafQKyZkIPWs7vv9tk4+ JyolQ7aAq25hDlitpJGDY4+Xz+/3/n+jZAtjoo+l+bHFi823mrgzLEAH4BUReHzr nyNQgIAk78TrsI9tPzAfdq5OHkjaMF5czTARz61HqjIfuXAo2bA1R+r8g/E7eCYi kU1yKjJetJgsTQZ2Umx+6Evx2C3G3/+USbiiKdTW9vuDJZ9uCpbCjfHGh6BSSGyW ell2WVCEq2yKgrf0+/aneRrNll3jI7AQMEoMHY7zoejipTdSOxM= =p1Fk -----END PGP SIGNATURE----- --Vsx21O/XFn/qaAE0--