gcc generated memcpy calls symbol version

gcc generated memcpy calls symbol version

[Tom Mason]

Hi,
I've got a project here: https://github.com/wheybags/glibc_version_header
which uses .symver directives to link to a specified version of glibc, so
long as it's older than the version on your system.
This works, but a problem I'm having is that gcc itself will sometimes
insert calls to memcpy (or memmove, memset and memcmp), as documented here:
https://gcc.gnu.org/onlinedocs/gcc/Standards.html
When it does so, it doesn't respect the .symver directives, and uses the
default version.
Is there any way for me to force the version for these symbols aswell?
I'm aware that I can disable the whole mechanism with -freestanding, but I
don't want to cripple the optimiser.
Regards,
Tom Mason

Re: gcc generated memcpy calls symbol version

[H.J. Lu]

On Fri, Jan 26, 2018 at 12:29 PM, Tom Mason <wheybags@wheybags.com> wrote:
> Hi,
> I've got a project here: https://github.com/wheybags/glibc_version_header
> which uses .symver directives to link to a specified version of glibc, so
> long as it's older than the version on your system.
> This works, but a problem I'm having is that gcc itself will sometimes
> insert calls to memcpy (or memmove, memset and memcmp), as documented here:
> https://gcc.gnu.org/onlinedocs/gcc/Standards.html
> When it does so, it doesn't respect the .symver directives, and uses the
> default version.
> Is there any way for me to force the version for these symbols aswell?
> I'm aware that I can disable the whole mechanism with -freestanding, but I
> don't want to cripple the optimiser.

I think this is related to:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220

-- 
H.J.

Re: gcc generated memcpy calls symbol version

[Tom Mason]

I'm not entirely sure I understand that issue. From what I understand,
calls to a function in a shared library should always use the PLT?
Also, I don't understand the purpose of applying hidden visibility to an
extern symbol,
But anyway, doesn't matter terribly much if I understand :p

On Fri, Jan 26, 2018 at 8:37 PM, H.J. Lu <hjl.tools@gmail.com> wrote:

> On Fri, Jan 26, 2018 at 12:29 PM, Tom Mason <wheybags@wheybags.com> wrote:
> > Hi,
> > I've got a project here: https://github.com/wheybags/
> glibc_version_header
> > which uses .symver directives to link to a specified version of glibc, so
> > long as it's older than the version on your system.
> > This works, but a problem I'm having is that gcc itself will sometimes
> > insert calls to memcpy (or memmove, memset and memcmp), as documented
> here:
> > https://gcc.gnu.org/onlinedocs/gcc/Standards.html
> > When it does so, it doesn't respect the .symver directives, and uses the
> > default version.
> > Is there any way for me to force the version for these symbols aswell?
> > I'm aware that I can disable the whole mechanism with -freestanding, but
> I
> > don't want to cripple the optimiser.
>
> I think this is related to:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220
>
> --
> H.J.
>

Re: gcc generated memcpy calls symbol version

[H.J. Lu]

On Fri, Jan 26, 2018 at 1:17 PM, Tom Mason <wheybags@wheybags.com> wrote:
> I'm not entirely sure I understand that issue. From what I understand, calls
> to a function in a shared library should always use the PLT?
> Also, I don't understand the purpose of applying hidden visibility to an
> extern symbol,

There is no need for PLT since hidden symbol is defined locally.  But
GCC ignores hidden visibility for libcalls, like memcpy.  If GCC treats
them like normal calls, your scheme and my testcase should work.


> But anyway, doesn't matter terribly much if I understand :p
>
> On Fri, Jan 26, 2018 at 8:37 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>> On Fri, Jan 26, 2018 at 12:29 PM, Tom Mason <wheybags@wheybags.com> wrote:
>> > Hi,
>> > I've got a project here:
>> > https://github.com/wheybags/glibc_version_header
>> > which uses .symver directives to link to a specified version of glibc,
>> > so
>> > long as it's older than the version on your system.
>> > This works, but a problem I'm having is that gcc itself will sometimes
>> > insert calls to memcpy (or memmove, memset and memcmp), as documented
>> > here:
>> > https://gcc.gnu.org/onlinedocs/gcc/Standards.html
>> > When it does so, it doesn't respect the .symver directives, and uses the
>> > default version.
>> > Is there any way for me to force the version for these symbols aswell?
>> > I'm aware that I can disable the whole mechanism with -freestanding, but
>> > I
>> > don't want to cripple the optimiser.
>>
>> I think this is related to:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220
>>
>> --
>> H.J.
>
>



-- 
H.J.

Re: gcc generated memcpy calls symbol version

[Tom Mason]

Actually, never mind, it's working fine:
https://gist.github.com/wheybags/b7e4152daf76c72503e9e1f52f3dca3d and I
have some other problem.


On Fri, Jan 26, 2018 at 9:22 PM, H.J. Lu <hjl.tools@gmail.com> wrote:

> On Fri, Jan 26, 2018 at 1:17 PM, Tom Mason <wheybags@wheybags.com> wrote:
> > I'm not entirely sure I understand that issue. From what I understand,
> calls
> > to a function in a shared library should always use the PLT?
> > Also, I don't understand the purpose of applying hidden visibility to an
> > extern symbol,
>
> There is no need for PLT since hidden symbol is defined locally.  But
> GCC ignores hidden visibility for libcalls, like memcpy.  If GCC treats
> them like normal calls, your scheme and my testcase should work.
>
>
> > But anyway, doesn't matter terribly much if I understand :p
> >
> > On Fri, Jan 26, 2018 at 8:37 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> >>
> >> On Fri, Jan 26, 2018 at 12:29 PM, Tom Mason <wheybags@wheybags.com>
> wrote:
> >> > Hi,
> >> > I've got a project here:
> >> > https://github.com/wheybags/glibc_version_header
> >> > which uses .symver directives to link to a specified version of glibc,
> >> > so
> >> > long as it's older than the version on your system.
> >> > This works, but a problem I'm having is that gcc itself will sometimes
> >> > insert calls to memcpy (or memmove, memset and memcmp), as documented
> >> > here:
> >> > https://gcc.gnu.org/onlinedocs/gcc/Standards.html
> >> > When it does so, it doesn't respect the .symver directives, and uses
> the
> >> > default version.
> >> > Is there any way for me to force the version for these symbols aswell?
> >> > I'm aware that I can disable the whole mechanism with -freestanding,
> but
> >> > I
> >> > don't want to cripple the optimiser.
> >>
> >> I think this is related to:
> >>
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220
> >>
> >> --
> >> H.J.
> >
> >
>
>
>
> --
> H.J.
>

Re: gcc generated memcpy calls symbol version

[Andi Kleen]

Tom Mason <wheybags@wheybags.com> writes:

> Is there any way for me to force the version for these symbols aswell?

It seems pointless because the ABI for these symbols will never change.

-Andi

Re: gcc generated memcpy calls symbol version

[Tom Mason]

Well, as I said, I was mistaken and the .symver directive does actually
work for this, but the point of forcing the version is to provide a
backwards compatible binary. If I compile with GCC on a modern system, it
might generate a call to memcpy@GLIBC_2.14, so then that binary won't run
on a system with glibc 2.13 installed. If I force it to an earlier version
however, then it'll work just fine.

On Jan 29, 2018 9:05 PM, "Andi Kleen" <ak@linux.intel.com> wrote:

> Tom Mason <wheybags@wheybags.com> writes:
>
> > Is there any way for me to force the version for these symbols aswell?
>
> It seems pointless because the ABI for these symbols will never change.
>
> -Andi
>