From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) by sourceware.org (Postfix) with ESMTPS id 4F94D386F471 for ; Sat, 2 May 2020 04:25:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4F94D386F471 Received: by mail-il1-x143.google.com with SMTP id q10so6254524ile.0 for ; Fri, 01 May 2020 21:25:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jLE8xsCaQHRGQQNGkJbYz4wLrOmt5S6Q7U7w0n2ez0A=; b=B61JoWK6rgru9j67pum7ZHUHmjXkY+kWd2wpnCS3RHSC43rxfTGEvyglgX9IwZn6X8 9QAbWACTx8DyRNOQu5sOSYunAjMhY72n+EFuV7xfBUG1tQObzm5c9k80dRizJPjKVRck AYqEu3aupFFN70W0nk66icMffP4ZSg7n9p+UMg565XiVLjVXpsYaCriB0cDgnZC5A26m 2zITL7omJ5KGswc+9IYFcltxTpE0C4rkvQxkC1yDaABMS0sbb+i2ws+M772jHpfWGw4/ aI4RqTi/4KTnC+aDCYqABWhGTJ3Bh4xwAgQc2BioDBZEZN8qIBU2qyXcCtuJmrDHs2PO AVMg== X-Gm-Message-State: AGi0PuZAc5vDr4mEJRM3R4iCz0OXPVvr2ImAYptSf0BQsOJzJluSkpET PCbPC/Qli5gtUv6cCU6wRVU+Bd/57XKPaduu2HrEQBdP X-Google-Smtp-Source: APiQypIL/jV6R1eqlWvAUrNe/9xBQ9Y2EKy38APZ4aYHJ/mHrSZI3tI6FxpDDNPqgQ/E7kaI3flagHoFEsapurjT9zE= X-Received: by 2002:a92:8dd5:: with SMTP id w82mr6751461ill.151.1588393503669; Fri, 01 May 2020 21:25:03 -0700 (PDT) MIME-Version: 1.0 References: <20200501055435.GF25855@bubble.grove.modra.org> <20200502032800.GI25855@bubble.grove.modra.org> In-Reply-To: <20200502032800.GI25855@bubble.grove.modra.org> From: "H.J. Lu" Date: Fri, 1 May 2020 21:24:27 -0700 Message-ID: Subject: Re: PR25882, .gnu.attributes are not checked for shared libraries To: Alan Modra Cc: Joseph Myers , Tulio Magno Quites Machado Filho , Binutils Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2020 04:25:16 -0000 On Fri, May 1, 2020 at 8:28 PM Alan Modra wrote: > > On Fri, May 01, 2020 at 04:48:38PM -0700, H.J. Lu wrote: > > On Fri, May 1, 2020 at 4:22 PM Joseph Myers w= rote: > > > > > > This binutils patch breaks glibc "make check" for big-endian powerpc > > > (32-bit and 64-bit). > > > > > > https://sourceware.org/pipermail/libc-testresults/2020q2/006097.html > > > > > > Errors of the form: > > > > > > /scratch/jmyers/glibc-bot/install/compilers/powerpc64-linux-gnu/lib/g= cc/powerpc64-glibc-linux-gnu/11.0.0/../../../../powerpc64-glibc-linux-gnu/b= in/ld: /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/mat= h/test-nldbl-redirect.o uses 64-bit long double, /scratch/jmyers/glibc-bot/= build/glibcs/powerpc64-linux-gnu/glibc/math/libm.so.6 uses 128-bit long dou= ble > > Hmm, is the Tag_GNU_Power_ABI_FP claim of ibm long double strictly > correct? Doesn't libm also support 64-bit long double too? In which > case libm ought to be silent about long double support. > > That of course can be accomplished by compiling all the object files > going into libm.so that provide long double functions (or call such > functions) with -mno-gnu-attributes. Another method with slightly > more finesse is to compile all files with the default -mgnu-attributes > but link with --no-warn-mismatch. That way the linker will not give > an error and also not emit the particular Tag with a conflict. (This > method assumes that assembly files emit the correct tags.) > > > > I don't know whether this is a problem with binutils, or it indicates= that > > > BE powerpc glibc needs to use -mno-gnu-attribute on some files like L= E > > > does to avoid such errors. > > > > It is odd to check .gnu.attributes on shared libraries since shared lib= raries > > used at link-time can be very different from run-time. > > You can say the same about many properties of shared libraries. > ld.gold on both arm and powerpc does check these attributes for shared > libraries. And it's necessary to use ld.gold to link split-stack and > non-split-stack object files if you want to ensure the non-split-stack > functions are called with something like the normal stack allocation. > If you use ld.bfd then non-split-stack functions might be called with > very small stacks. So arm and powerpc have a history of checking > shared library .gnu.attributes. > > > Checking .gnu.attributes > > on shared libraries gives you very little. > > Checking .gnu.attributes protects the user from linking against a > shared library that say, provides ibm long double math function when > the user is compiling for ieee long double. That was the idea behind > the binutils patch. There are of course some negatives, chief of > which is that .gnu.attributes is nowhere near fine enough grained to > work well with libraries that provide multiple areas of support. You > may hit a link error regarding functions you do not use in your app. > I don't think checking .gnu.attributes in shared libraries at link-time can protect shared libraries with different long double math functions at run-time. That is the main reason why I introduced .note.gnu.property section. --=20 H.J.