From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id B4F80385DC31 for ; Wed, 1 Apr 2020 10:21:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B4F80385DC31 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-478-9XoLp_u2PGmshO59axRIUg-1; Wed, 01 Apr 2020 06:21:47 -0400 X-MC-Unique: 9XoLp_u2PGmshO59axRIUg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E5AEC8017CC; Wed, 1 Apr 2020 10:21:45 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-113-15.ams2.redhat.com [10.36.113.15]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 71FF060BE2; Wed, 1 Apr 2020 10:21:43 +0000 (UTC) From: Florian Weimer To: Szabolcs Nagy Cc: Fangrui Song , GNU C Library , gnu-gabi , Mark Wielaard , "Zhang\, Annita" , Binutils , Cary Coutant , "Liu\, Hongtao" Subject: Re: binutils ld and new PT_GNU_PROPERTY segment References: <2e29243995903cf2d52975543675f2b92fa1e201.camel@klomp.org> <20200222051913.meiied65a5daylvk@google.com> <87tv231tkt.fsf@oldenburg2.str.redhat.com> <20200401092253.GM27072@arm.com> <87ftdnzh8q.fsf@oldenburg2.str.redhat.com> <20200401101002.GO27072@arm.com> Date: Wed, 01 Apr 2020 12:21:41 +0200 In-Reply-To: <20200401101002.GO27072@arm.com> (Szabolcs Nagy's message of "Wed, 1 Apr 2020 11:10:02 +0100") Message-ID: <87lfnfy096.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gnu-gabi@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnu-gabi mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 10:21:52 -0000 * Szabolcs Nagy: > The 04/01/2020 11:29, Florian Weimer wrote: >> * Szabolcs Nagy: >> > why only -r is problematic? >> > >> > i thought linking exactly one marked object and other non-marked >> > ones with an old linker will have the (incorrect) marking on the >> > output that cannot be recognised as wrong. >>=20 >> Where do you get that single marked object? >>=20 >> If you are on a CET-enabled distribution, the startup files are marked, >> so you have multiple marked objects right there. > > assume your toolchain is not cet enabled (and has an old > linker) but you link in a library archive that is cet > enabled (because it was given to you that way) and exactly > one .o from it gets used during the link. > > the resulting binary will have the marking and if deployed > on a cet enabled system it won't work. (at least this is > my current understanding.) But that's not something we currently support. We do not have ABI stability for static linking like this. You are more likely to run into problems due to other issues (e.g., missing glibc symbols) than incorrect CET markup. Thanks, Florian