From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by sourceware.org (Postfix) with ESMTPS id 8B427385AC19 for ; Fri, 17 Sep 2021 17:40:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8B427385AC19 Received: by mail-pj1-x1030.google.com with SMTP id me5-20020a17090b17c500b0019af76b7bb4so9864825pjb.2 for ; Fri, 17 Sep 2021 10:40:27 -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=G+3RvFfXXxlXnTGr68aLeu6SWP71AZ4vlpi5IZUJ/QI=; b=dYqHxRTSEnZaHp4pNVFHayLdfaAMR+56HzG3ilLjJxjKa/rxROlt4MzNP/UZXUTq1R 3317JXC+Onmb4z61SOW70UffPcImGv9dbsQFo98QDDi8A3EftBwwti22bbYHgVbZz8EE vXM0Uxzr5QsVVJ5rRPcxn0PC3pIMxRDUaV1JwAWvB0Alz1ZdRfMIqaGnWbQNVmTSAb2o +9d9dL/vfjJshk6FRN09NPiEws6zyp9qPYVZne39yCSuxicA6IhJbc9vLLFb18KgF0ex uTDJGDvJmaQ1B99sop5T4kVB8nESEGpkzJJnYu4a97QqsnyBJZ+65u8eYOb0L9ArHBkA GAOw== X-Gm-Message-State: AOAM530y+p6wcFAx7m3LazIVy4QYbxg/XygkI8O0I06aXBhFD/4L+guU 8uSWDIUdyfNM806kZkVKJR4HkbrzP5l+GcNn91g= X-Google-Smtp-Source: ABdhPJx8TPIkS665RmvvX3j/FjlnfxsAht+CGbSVzBy62vUL2qbMiH0yopjjvK7VV8hFZhH3Xm5Hld9gm94sSHpJOKU= X-Received: by 2002:a17:90b:1644:: with SMTP id il4mr10078334pjb.87.1631900426712; Fri, 17 Sep 2021 10:40:26 -0700 (PDT) MIME-Version: 1.0 References: <87y27vhbel.fsf@oldenburg.str.redhat.com> In-Reply-To: From: Noah Goldstein Date: Fri, 17 Sep 2021 12:40:15 -0500 Message-ID: Subject: Re: [libc-coord] Add new ABI '__memcmpeq()' to libc To: Richard Biener Cc: Florian Weimer , Richard Biener via Gcc , GNU C Library , Joseph Myers , libc-coord@lists.openwall.com X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 17:40:29 -0000 On Fri, Sep 17, 2021 at 3:32 AM Richard Biener via Gcc wrote: > 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. > Where would the jmp be and under what conditions? Is there no way to achieve this with zero overhead? > > > 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 > > >