This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: having trouble making my version of pthread_condattr_init/destroy visible to outside world




Ok, I think i found a way to fix this. For some reason it was not enough to add pthread_foocondattr_init/destroy to the same sections of the nptl/Versions file where pthread_condattr_init/destroy where located. So I added my pthread_foocondattr_init/destroy to other sections of nptl/Versions and now it's symbol is visible globally. Is this right?

Another problem I'm encountering is that the source code I'm using to test my API's (I'm compiling it with this custom glibc) I make a call to clock_gettime() and it says it's undefined. I have <time.h> included, which according to the man pages for clock_gettime() is the header that includes it.



----- Original Message ----
From: Daniel De La Zerda <ddelazerda007@yahoo.com>
To: Ryan Arnold <ryan.arnold@gmail.com>
Cc: Carlos O'Donell <carlos@systemhalted.org>; libc-help@sourceware.org
Sent: Wednesday, April 15, 2009 3:03:22 PM
Subject: Re: having trouble making my version of pthread_condattr_init/destroy  visible to outside world


>If you strong alias pthread_foocondattr_init to pthread_condattr_init

>then your entry point is now pthread_condattr_init, not
>pthread_foocondattr_init.

I strong alias'ed __pthread_foocondattr_init to pthread_foocondattr_init.

>Did you perform hidden_proto(pthread_foocondattr_init) on the
>prototype definition and hidden_def(pthread_foocondattr_init) on the
>implementation?  If so then you've asked the compiler to hide the
>internal symbol name.

No. I have not used hidden_proto() nor hidden_def().

>If you look at the addresses in objdump of pthread_condattr_init and
>pthread_foocondattr_init they should have the same address.

Yes, when I do "nm libpthread.so | grep pthread_foocondattr_init", both "pthread_foocondattr_init" and "__pthread_foocondattr_init" show up with the same address but both have a "t" besides them, whereas I was expecting "pthread_foominicondattr_init" to have a "T" besides it - be globally visible.




----- Original Message ----
From: Ryan Arnold <ryan.arnold@gmail.com>
To: Daniel De La Zerda <danieldelazerda@gmail.com>
Cc: Carlos O'Donell <carlos@systemhalted.org>; libc-help@sourceware.org
Sent: Wednesday, April 15, 2009 2:40:00 PM
Subject: Re: having trouble making my version of pthread_condattr_init/destroy  visible to outside world

On Wed, Apr 15, 2009 at 1:16 PM, Daniel De La Zerda
<ddelazerda007@yahoo.com> wrote:
>
> Hi, I have my versions of the pthread_foocondattr_init/destroy functions and when I compile code using them I get "undefined reference" errors. I have added these two functions inside the nptl/Versions file. At the bottom of their function definition files I added strong_alias() following the same convention as in the regular pthread_condattr_init/destroy. Their symbols get exported but both symbols __pthread_foocondattr_init/destroy and pthread_foocondattr_init/destroy show with a small "t" next to their names. I was expecting the pthread_foocondattr_init/destroy symbol should have "T" which then would mean that their are visible to the outside world. On the other hand the pthread_condattr_init/destroy functions that come with glibc do show up with "T".

If you look at the addresses in objdump of pthread_condattr_init and
pthread_foocondattr_init they should have the same address.

Did you perform hidden_proto(pthread_foocondattr_init) on the
prototype definition and hidden_def(pthread_foocondattr_init) on the
implementation?  If so then you've asked the compiler to hide the
internal symbol name.

If you strong alias pthread_foocondattr_init to pthread_condattr_init
then your entry point is now pthread_condattr_init, not
pthread_foocondattr_init.

This is often done for three reasons:

1.) To allow different backend implementations to have a common front-end.
2.) To allow GLIBC to internally invoke the internal symbol without
going through the PLT, i.e. static function invocation.
3.) strong-alias disallows external override of the internal
implementation, meaning if you don't want the user to override the
internal implementation you can use a strong alias.

Perhaps a relevant snippet of your header file and implementation
would be in order.

Ryan


      


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]