From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by sourceware.org (Postfix) with ESMTPS id 5F0173858D29 for ; Fri, 17 Sep 2021 09:31:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5F0173858D29 Received: by mail-ed1-x52a.google.com with SMTP id t6so27637079edi.9 for ; Fri, 17 Sep 2021 02:31:02 -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=+jCDsxKmjrhI+TXxGkSCFV0RGssIgMxbi/roE2Ku5Tc=; b=rAEmj5OwljvGEPCwNNcQxQuLVuXyTPmolWkhFXCXweYGKNZgMY1MlR+KW8kzn7SJia 8UNGFNn/86wWcMTV9flgFA5Erkba5hOGt/jmofSIEEba/nUfI5FRGbAl7wKSfiM3/BHK irnsFVFKs3Zb/8cvZnRUs/cKM9vMIzAQfvLjmXYw/DyXP+ovaoRpzdOzcFR2odl686yW KQzdqtd0P9bfP4CcU7cJWr2M3ospBz/nKHlRi5JAVtkTmJzN6YInllHYRy5NPPktHea6 GgpyD9SkWCOAS9/mex1PHGXWrBXYfjtNHyytlzcoXnh4jU/sebj78/oRNeap5b1o/ocN 8rpQ== X-Gm-Message-State: AOAM530McMBg62fyNNnZqMTgeEtgsfBavLLYBHEcz0lyX1cGmmfOFmLT BC5/F9III4ZH4dfdKoEC5v7osJa8TAsG+3Xk/+Y= X-Google-Smtp-Source: ABdhPJyJtbMUzmj4EFWZrcWx4IBj9Dv3KLkXS4Y0WqRuFzujUNveIoDcr3gHSSe7LW2V95zJGCwyv6qIUrYTZWjQhcQ= X-Received: by 2002:a17:906:fa05:: with SMTP id lo5mr10913561ejb.204.1631871061270; Fri, 17 Sep 2021 02:31:01 -0700 (PDT) MIME-Version: 1.0 References: <87y27vhbel.fsf@oldenburg.str.redhat.com> <87lf3vha27.fsf@oldenburg.str.redhat.com> In-Reply-To: <87lf3vha27.fsf@oldenburg.str.redhat.com> From: Richard Biener Date: Fri, 17 Sep 2021 11:30:50 +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 Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.6 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.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 09:31:05 -0000 On Fri, Sep 17, 2021 at 10:37 AM Florian Weimer wrote: > > * Richard Biener: > > > 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. > > How would this look like in practice. > > The GNU tools do not support weak symbol versions, so if you have a weak > reference to __memcmpeq@GLIBC_2.35, that's still a reference to the > GLIBC_2.35 symbol version. The glibc 2.34 dynamic loader notes that > version and rejects the binary because GLIBC_2.35 does not exist. Aww, symbol versions. Yeah, that makes it difficult ... Anyway, with a declaration available it's good enough I think. Richard. > (We should probably stop Cc:ing libc-coord because this is so very > GNU-specific at this point.) > > Thanks, > Florian >