.symver

.symver

[Tom Kacvinsky]

Hi,

I am in the process of building some software were I inject .symver
instructions into the assembly generated by GCC, then assembly it.  What I
found is .symver actually inserts the symbol that is
referred to in the instruction into the object code, which causes problems
later down the road.  For example, there are some pthreads functions that
end up in object code used to build a shared
library, ones that can be resolved by linking in the pthreads library.
However, I don't want to link
in that library if I can avoid it.  Is there a way to tell the linker to
not use those symbols if they are
not used  in the generated object code?

Thanks,

Tom

Re: .symver

[Nick Clifton]

Hi Tom,

> I am in the process of building some software were I inject .symver
> instructions into the assembly generated by GCC, then assembly it.  What I
> found is .symver actually inserts the symbol that is
> referred to in the instruction into the object code, which causes problems
> later down the road.

You could make the .symver directive conditional upon the symbol already
being defined by:

   .ifdef SYM
   .symver SYM, NAME2
   .endif

> Is there a way to tell the linker to
> not use those symbols if they are
> not used  in the generated object code?

Well if the symbol is in an archive library (eg libfoo.a) then it will only
be pulled into the link if it is needed, or other symbols in object file
containing it are needed.

You might also be able to use the visibility argument to .symver to solve
the problem.  If you make the symbols internal for example then they should
not trigger the loading of other libraries.

Cheers
   Nick

Re: .symver

[Tom Kacvinsky]

I have made more progress on this and it looks to me, for the code I
am working with,
that .symver overrides a symbol being marked as weak.  So

.weak pthread_key_create
.symver pthread_key_create, pthread_key_create@GLIBC_2.2.5

Removes the symbol as being marked weak and wants to resolve against
pthread_key_create@GLIBC_2.2.5.
That's what I've observed anyway.  Sample code is

#include <stdio.h>
#include <pthread.h>

extern int pthread_key_create (pthread_key_t *, void (*) (void *))
__attribute__ ((weak));
__asm__(".symver pthread_key_create,pthread_key_create@GLIBC_2.2.5");

void destructor(void* arg) { return; }

void thread_func() {
  pthread_key_t key;

  pthread_key_create(&key, destructor);
}

 gcc -fPIC -o thread.so -save-temps -shared thread.c
ld: error: symbol pthread_key_create has undefined version GLIBC_2.2.5
collect2: error: ld returned 1 exit status

Using binutils 2.34, but also happens with binutils 2.35.1

Tom


On Wed, Jan 13, 2021 at 6:23 AM Nick Clifton <nickc@redhat.com> wrote:
>
> Hi Tom,
>
> > I am in the process of building some software were I inject .symver
> > instructions into the assembly generated by GCC, then assembly it.  What I
> > found is .symver actually inserts the symbol that is
> > referred to in the instruction into the object code, which causes problems
> > later down the road.
>
> You could make the .symver directive conditional upon the symbol already
> being defined by:
>
>    .ifdef SYM
>    .symver SYM, NAME2
>    .endif
>
> > Is there a way to tell the linker to
> > not use those symbols if they are
> > not used  in the generated object code?
>
> Well if the symbol is in an archive library (eg libfoo.a) then it will only
> be pulled into the link if it is needed, or other symbols in object file
> containing it are needed.
>
> You might also be able to use the visibility argument to .symver to solve
> the problem.  If you make the symbols internal for example then they should
> not trigger the loading of other libraries.
>
> Cheers
>    Nick
>

Re: .symver

[H.J. Lu]

On Tue, Jan 19, 2021 at 6:28 AM Tom Kacvinsky via Binutils
<binutils@sourceware.org> wrote:
>
> I have made more progress on this and it looks to me, for the code I
> am working with,
> that .symver overrides a symbol being marked as weak.  So
>
> .weak pthread_key_create
> .symver pthread_key_create, pthread_key_create@GLIBC_2.2.5
>
> Removes the symbol as being marked weak and wants to resolve against
> pthread_key_create@GLIBC_2.2.5.
> That's what I've observed anyway.  Sample code is
>
> #include <stdio.h>
> #include <pthread.h>
>
> extern int pthread_key_create (pthread_key_t *, void (*) (void *))
> __attribute__ ((weak));
> __asm__(".symver pthread_key_create,pthread_key_create@GLIBC_2.2.5");
>
> void destructor(void* arg) { return; }
>
> void thread_func() {
>   pthread_key_t key;
>
>   pthread_key_create(&key, destructor);
> }
>
>  gcc -fPIC -o thread.so -save-temps -shared thread.c
> ld: error: symbol pthread_key_create has undefined version GLIBC_2.2.5
> collect2: error: ld returned 1 exit status
>
> Using binutils 2.34, but also happens with binutils 2.35.1
>

I made some improvements to .symver in binutils 2.36.  They may help you.

-- 
H.J.

Re: .symver

[Tom Kacvinsky]

I cloned the git repo for binutils-gdb, but don't see a tag for 2.36.
The last commit I see when running git log is

ccbe4c82d5219502806dc62aa1cf51e5b1a4b479

on December 23rd 2020

Tom

On Tue, Jan 19, 2021 at 9:51 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Tue, Jan 19, 2021 at 6:28 AM Tom Kacvinsky via Binutils
> <binutils@sourceware.org> wrote:
> >
> > I have made more progress on this and it looks to me, for the code I
> > am working with,
> > that .symver overrides a symbol being marked as weak.  So
> >
> > .weak pthread_key_create
> > .symver pthread_key_create, pthread_key_create@GLIBC_2.2.5
> >
> > Removes the symbol as being marked weak and wants to resolve against
> > pthread_key_create@GLIBC_2.2.5.
> > That's what I've observed anyway.  Sample code is
> >
> > #include <stdio.h>
> > #include <pthread.h>
> >
> > extern int pthread_key_create (pthread_key_t *, void (*) (void *))
> > __attribute__ ((weak));
> > __asm__(".symver pthread_key_create,pthread_key_create@GLIBC_2.2.5");
> >
> > void destructor(void* arg) { return; }
> >
> > void thread_func() {
> >   pthread_key_t key;
> >
> >   pthread_key_create(&key, destructor);
> > }
> >
> >  gcc -fPIC -o thread.so -save-temps -shared thread.c
> > ld: error: symbol pthread_key_create has undefined version GLIBC_2.2.5
> > collect2: error: ld returned 1 exit status
> >
> > Using binutils 2.34, but also happens with binutils 2.35.1
> >
>
> I made some improvements to .symver in binutils 2.36.  They may help you.
>
> --
> H.J.

Re: .symver

[H.J. Lu]

On Tue, Jan 19, 2021 at 7:28 AM Tom Kacvinsky via Binutils
<binutils@sourceware.org> wrote:
>
> I cloned the git repo for binutils-gdb, but don't see a tag for 2.36.
> The last commit I see when running git log is
>
> ccbe4c82d5219502806dc62aa1cf51e5b1a4b479

There is no such commit in

https://sourceware.org/git/?p=binutils-gdb.git;a=summary

> on December 23rd 2020
>
> Tom
>

Use binutils-2_36-branch branch.

-- 
H.J.

Re: .symver

[Tom Kacvinsky]

Maybe I go the wrong git repo, because:

-bash-4.4$ git checkout  binutils-2_36-branch
error: pathspec 'binutils-2_36-branch' did not match any file(s) known to git

What is the official repo?

Tom
On Tue, Jan 19, 2021 at 10:35 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Tue, Jan 19, 2021 at 7:28 AM Tom Kacvinsky via Binutils
> <binutils@sourceware.org> wrote:
> >
> > I cloned the git repo for binutils-gdb, but don't see a tag for 2.36.
> > The last commit I see when running git log is
> >
> > ccbe4c82d5219502806dc62aa1cf51e5b1a4b479
>
> There is no such commit in
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=summary
>
> > on December 23rd 2020
> >
> > Tom
> >
>
> Use binutils-2_36-branch branch.
>
> --
> H.J.

Re: .symver

[H.J. Lu]

On Tue, Jan 19, 2021 at 7:39 AM Tom Kacvinsky via Binutils
<binutils@sourceware.org> wrote:
>
> Maybe I go the wrong git repo, because:
>
> -bash-4.4$ git checkout  binutils-2_36-branch
> error: pathspec 'binutils-2_36-branch' did not match any file(s) known to git
>
> What is the official repo?

See URL in my previous email.

> Tom
> On Tue, Jan 19, 2021 at 10:35 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Tue, Jan 19, 2021 at 7:28 AM Tom Kacvinsky via Binutils
> > <binutils@sourceware.org> wrote:
> > >
> > > I cloned the git repo for binutils-gdb, but don't see a tag for 2.36.
> > > The last commit I see when running git log is
> > >
> > > ccbe4c82d5219502806dc62aa1cf51e5b1a4b479
> >
> > There is no such commit in
> >
> > https://sourceware.org/git/?p=binutils-gdb.git;a=summary
> >
> > > on December 23rd 2020
> > >
> > > Tom
> > >
> >
> > Use binutils-2_36-branch branch.
> >
> > --
> > H.J.



-- 
H.J.

Re: .symver

[Tom Kacvinsky]

OK, I got the right repo and built the 2.36 branch.  However, using
the newish visibility attribute (local,
hidden and remove), none  of them fixes the problem.  I still think
.symver is overloading what .weak is
supposed to do.

om

On Tue, Jan 19, 2021 at 11:17 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Tue, Jan 19, 2021 at 7:39 AM Tom Kacvinsky via Binutils
> <binutils@sourceware.org> wrote:
> >
> > Maybe I go the wrong git repo, because:
> >
> > -bash-4.4$ git checkout  binutils-2_36-branch
> > error: pathspec 'binutils-2_36-branch' did not match any file(s) known to git
> >
> > What is the official repo?
>
> See URL in my previous email.
>
> > Tom
> > On Tue, Jan 19, 2021 at 10:35 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > On Tue, Jan 19, 2021 at 7:28 AM Tom Kacvinsky via Binutils
> > > <binutils@sourceware.org> wrote:
> > > >
> > > > I cloned the git repo for binutils-gdb, but don't see a tag for 2.36.
> > > > The last commit I see when running git log is
> > > >
> > > > ccbe4c82d5219502806dc62aa1cf51e5b1a4b479
> > >
> > > There is no such commit in
> > >
> > > https://sourceware.org/git/?p=binutils-gdb.git;a=summary
> > >
> > > > on December 23rd 2020
> > > >
> > > > Tom
> > > >
> > >
> > > Use binutils-2_36-branch branch.
> > >
> > > --
> > > H.J.
>
>
>
> --
> H.J.

Re: .symver

[H.J. Lu]

On Tue, Jan 19, 2021 at 8:20 AM Tom Kacvinsky via Binutils
<binutils@sourceware.org> wrote:
>
> OK, I got the right repo and built the 2.36 branch.  However, using
> the newish visibility attribute (local,
> hidden and remove), none  of them fixes the problem.  I still think
> .symver is overloading what .weak is
> supposed to do.
>

Open a binutls bug with a complete testcase.  I will take a look.

-- 
H.J.

Re: .symver

[Tom Kacvinsky]

H.J.,

Done.  Here it is: https://sourceware.org/bugzilla/show_bug.cgi?id=27206

Tom

On Tue, Jan 19, 2021 at 11:48 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Tue, Jan 19, 2021 at 8:20 AM Tom Kacvinsky via Binutils
> <binutils@sourceware.org> wrote:
> >
> > OK, I got the right repo and built the 2.36 branch.  However, using
> > the newish visibility attribute (local,
> > hidden and remove), none  of them fixes the problem.  I still think
> > .symver is overloading what .weak is
> > supposed to do.
> >
>
> Open a binutls bug with a complete testcase.  I will take a look.
>
> --
> H.J.

Re: .symver

[Tom Kacvinsky]

On Tue, Jan 19, 2021 at 12:39 PM Tom Kacvinsky <tkacvins@gmail.com> wrote:
>
> H.J.,
>
> Done.  Here it is: https://sourceware.org/bugzilla/show_bug.cgi?id=27206
>
> Tom
>
> On Tue, Jan 19, 2021 at 11:48 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Tue, Jan 19, 2021 at 8:20 AM Tom Kacvinsky via Binutils
> > <binutils@sourceware.org> wrote:
> > >
> > > OK, I got the right repo and built the 2.36 branch.  However, using
> > > the newish visibility attribute (local,
> > > hidden and remove), none  of them fixes the problem.  I still think
> > > .symver is overloading what .weak is
> > > supposed to do.
> > >
> >
> > Open a binutls bug with a complete testcase.  I will take a look.
> >

I know better, but I've been top posting.  I won't do that again,

Tom