From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cygnus.enyo.de (cygnus.enyo.de [79.140.189.114]) by sourceware.org (Postfix) with ESMTPS id A98483858D38 for ; Mon, 12 Feb 2024 19:29:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A98483858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=deneb.enyo.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A98483858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=79.140.189.114 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707766149; cv=none; b=wJUzbpF4PG55OMSn6uiUkUNepqWVM2eea5jv0/BKZrjcXC8VdAztU9rlpnaMd3SbKKhA/KNXWkiIKUo0pg3DyVN7xKlntluFF0p+ULnATs1KvIHM2eJjUQ/tIqzJIIP/trgC8EyNM6chTk3+9Z5UUqm/TTiEsX1+3n9fkW089Sc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707766149; c=relaxed/simple; bh=8NOaeHVPDNo8rB1HiQkqCGXrsSM1uoQr9uYVQ2AKM1I=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=hxagY3Bzng69F0wDU6BnwNi9E5wLPOrhX8xvJo5LfY0N+cUrTpfSK7MuTYno34G13UwX0OAqnLHOdMfNMX1coXNEIWIq0mF3MN0Moj9h1j++DtTRAeRpiQXmlpgnBIk42V7tuTloBmZnFp2kfGnAvSOjVDP6XkDY0NMcay/3wCc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [172.17.203.2] (port=33499 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) id 1rZbzD-00GVAw-NE; Mon, 12 Feb 2024 19:29:03 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.96) (envelope-from ) id 1rZbzD-000A54-1w; Mon, 12 Feb 2024 20:29:03 +0100 From: Florian Weimer To: Andreas Schwab Cc: Adhemerval Zanella Netto , Florian Weimer , libc-alpha@sourceware.org Subject: Re: [PATCH 01/11] misc: Build getdomainname with fortification References: <7710004342d09a8e62868a0bc659b5dca5b67324.1707491940.git.fweimer@redhat.com> <8623972a-5966-4953-b537-72bcde371a68@linaro.org> Date: Mon, 12 Feb 2024 20:29:03 +0100 In-Reply-To: (Andreas Schwab's message of "Mon, 12 Feb 2024 18:30:15 +0100") Message-ID: <87a5o58osg.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Andreas Schwab: > On Feb 12 2024, Adhemerval Zanella Netto wrote: > >> On 09/02/24 12:24, Florian Weimer wrote: >>> Introduce __glibc_nofortify_getdomainname to request disabling >>> the fortification wrapper. >> >> I am not very found of __glibc_nofortify_getdomainname escaping to an >> installed header, but I don't have a better solution. > > Can't this be fixed with an alias? It would have to be an assembler-level alias that GCC doesn't know about. Would you prefer that? It results in worse debugging information, I think. GCC's alias attribyte counts a definition, and we already have one due to the inline function definition in the fortify header.