Date: Fri, 17 Sep 2021 10:31:54 +0200 From: Richard Biener <richard.guenther@...il.com> To: Florian Weimer <fweimer@...hat.com> Cc: Richard Biener via Gcc <gcc@....gnu.org>, Joseph Myers <joseph@...esourcery.com>, GNU C Library <libc-alpha@...rceware.org>, libc-coord@...ts.openwall.com Subject: Re: Add new ABI '__memcmpeq()' to libc On Fri, Sep 17, 2021 at 10:08 AM Florian Weimer <fweimer@...hat.com> wrote: > > * Richard Biener via Gcc: > > > On Thu, Sep 16, 2021 at 10:36 PM Joseph Myers <joseph@...esourcery.com> 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 thing. Richard. > 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.