John Polstra writes:
> > > I think it would work if the symbol were defined strongly in libc_r.
> > 
> > I think so too. I was trying to work out why this wasn't how things were
> > done already. FWIW, linux's libpthread appears to be defining the
> > pthread_* symbols strongly.
> 
> I think the weak symbols have something to do with support for thread
> cancellation.  I didn't pay much attention at the time, so I don't
> know the details.  Here's the relevant commit message, I think (this
> one taken from lib/libc_r/uthread/uthread_pause.c):
> 
>   date: 2001/01/24 13:03:34;  author: deischen;  state: Exp;  lines: +4 -4
>   Add weak definitions for wrapped system calls.  In general:
> 
>         _foo - wrapped system call
>         foo - weak definition to _foo
> 
>   and for cancellation points:
> 
>         _foo - wrapped system call
>         __foo - enter cancellation point, call _foo(), leave
>                 cancellation point
>         foo - weak definition to __foo

To me it appears that weak symbols are not related to thread cancellation
other than by coincidence. All this commit is saying is that the functionality
of the libc_r version of "foo()" is split into two functions, one of
which is a public entry point (__foo()) and the other of which is for
internal use by libc_r (_foo()). The public entry point just calls the
internal version after satisfying the requirement that the function
be a cancellation point.

In other words, weak symbol are used for non-cancellation point functions
as well, and are not required for implemention cancellation points.

It might have been slightly clearer if the _foo and __foo names had been
reversed, so that "foo" always weakly referenced "_foo" whether or not
the function was a cancellation point. But that would have probably
caused a lot of changes in existing code (?).

-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to