[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFUsyfKWs9vtZ=Z0bNAiStfmfxCUaMRtgPPPjGCXjXqLapAMZg@mail.gmail.com>
Date: Fri, 17 Sep 2021 12:40:15 -0500
From: Noah Goldstein <goldstein.w.n@...il.com>
To: Richard Biener <richard.guenther@...il.com>
Cc: Florian Weimer <fweimer@...hat.com>, Richard Biener via Gcc <gcc@....gnu.org>,
GNU C Library <libc-alpha@...rceware.org>, Joseph Myers <joseph@...esourcery.com>,
libc-coord@...ts.openwall.com
Subject: Re: Add new ABI '__memcmpeq()' to libc
On Fri, Sep 17, 2021 at 3:32 AM Richard Biener via Gcc <gcc@....gnu.org>
wrote:
> 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.
>
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
> >
>
Content of type "text/html" skipped
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.
