libc-coord - Re: Add new ABI '_

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87y27vhbel.fsf@oldenburg.str.redhat.com>
Date: Fri, 17 Sep 2021 10:08:34 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Richard Biener via Gcc <gcc@....gnu.org>
Cc: Joseph Myers <joseph@...esourcery.com>,  Richard Biener
 <richard.guenther@...il.com>,  GNU C Library <libc-alpha@...rceware.org>,
  libc-coord@...ts.openwall.com
Subject: Re: Add new ABI '__memcmpeq()' to libc

* 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.

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.

> (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?

Thanks,
Florian

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