From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by sourceware.org (Postfix) with ESMTPS id A16C1385AC1B for ; Fri, 17 Sep 2021 08:32:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A16C1385AC1B Received: by mail-ed1-x532.google.com with SMTP id n10so26498873eda.10 for ; Fri, 17 Sep 2021 01:32:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uP3ODqRZxfe6HuBdEMxa64LebV5yDsdqqt/2RnTqJKc=; b=Wyaegms+jDKTFPNwNgOgyLTQlvL+7KhcFox8GhByoWqPIPCkiK04VwTazBIokyfo3y rm7WYx8esTSU0Sb/pFhtQPgKAUxyTDggnpT6r2uS7IyCKsezHHV94tupTD2Ubc2jfcs+ lolmYu/xCWgJKpb9bUkFa+kJpuuIIXfR43zM4N87gUegcyDX2TvowWnURbC/HTRJSQQ3 jtk5o+5P7izd5QPfUwBeF5TNIGGKYMWkVJFQX8nsa2DJZHUOLB7oLUhmIGHrQ7OelEnr yjPvZrjW7KTIYr5GNa2KlKJacQsGvJOZE1huLMim38GoDGHtvFTV5PRTz8OmkH/drQrR w58A== X-Gm-Message-State: AOAM530/bJ5+BhU8NLtuRTL7635W8+zkaaeBD0aJoAPEkMGTSmuSEgBI GW3uwmbd6w9KwdbBXyTqqGJKC0Ddh9ZWbNe4b0Y= X-Google-Smtp-Source: ABdhPJwFAYiMDTgqVK0J5BxTOrON7oaEhbC/jZhsTBn20FkSu2Pa9wcAlyOB0Dih1ysueoiLj9friZno7lokOSWnEow= X-Received: by 2002:a05:6402:88e:: with SMTP id e14mr11577729edy.342.1631867525898; Fri, 17 Sep 2021 01:32:05 -0700 (PDT) MIME-Version: 1.0 References: <87y27vhbel.fsf@oldenburg.str.redhat.com> In-Reply-To: <87y27vhbel.fsf@oldenburg.str.redhat.com> From: Richard Biener Date: Fri, 17 Sep 2021 10:31:54 +0200 Message-ID: Subject: Re: [libc-coord] Add new ABI '__memcmpeq()' to libc To: Florian Weimer Cc: Richard Biener via Gcc , Joseph Myers , GNU C Library , libc-coord@lists.openwall.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.5 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=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2021 08:32:09 -0000 On Fri, Sep 17, 2021 at 10:08 AM Florian Weimer wrote: > > * Richard Biener via Gcc: > > > On Thu, Sep 16, 2021 at 10:36 PM Joseph Myers wrote: > >> > >> On Thu, 16 Sep 2021, Chris Kennelly wrote: > >> > >> > In terms of relying on the feature: If __memcmpeq is ever exposed as an a > >> > simple alias for memcmp (since the notes mention that it's a valid > >> > implementation), does that open up the possibility of depending on the > >> > bcmp-like behavior that we were trying to escape? > >> > >> The proposal is as an ABI only (compilers would generate calls to > >> __memcmpeq from boolean uses of memcmp, users wouldn't write calls to > >> __memcmpeq directly, __memcmpeq wouldn't be declared in installed libc > >> headers). If such dependence arises, that would suggest a compiler bug > >> wrongly generating such calls for non-boolean memcmp uses. > > > > So the compiler would emit a call to __memcmpeq and at the same time > > emit a weak alias of __memcmpeq to memcmp so the program links > > when the libc version targeted does not provide __memcmpeq? Or would > > glibc through magically communicate the availability of the new ABI > > without actually declaring the function? > > I do not think ELF provides that capability. I guess a weak forwarder should do the trick at the cost of a jmp. > We can add a declaration to to communicate the availability. > I think this is how glibc (and other libcs) communicate the availability > of non-standard interfaces to GCC. OK, I guess that's fine. > > (I'm not sure whether a GCC build-time decision via configure is the > > very best idea) > > If libstdc++ or libgcc_s have a symbol dependency on glibc 2.35 for > other (unrelated) reasons, would the build-time dependency be less of a > concern? Because another such dependency exists? Not sure, I was thinking that we'd need to re-compile GCC when we upgrade glibc to make use of the feature. But then being able to run an executable on a system that does not provide the ABI but a compatible one (memcmp) might be a nice thing. Richard. > Thanks, > Florian >