On Fri, Sep 17, 2021 at 3:32 AM Richard Biener via Gcc <gcc@gcc.gnu.org> wrote:
> On Fri, Sep 17, 2021 at 10:08 AM Florian Weimer <fwei...@redhat.com> > wrote: > > > > * Richard Biener via Gcc: > > > > > On Thu, Sep 16, 2021 at 10:36 PM Joseph Myers <jos...@codesourcery.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. > 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 <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 > > >
