Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Sep 2021 10:31:54 +0200
From: Richard Biener <>
To: Florian Weimer <>
Cc: Richard Biener via Gcc <>, Joseph Myers <>, 
	GNU C Library <>,
Subject: Re: Add new ABI '__memcmpeq()' to libc

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 <string.h> 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 <string.h> 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


> Thanks,
> Florian

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.