Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Jan 2000 12:49:32 -0600
From:      "Richard Seaman, Jr." <dick@tar.com>
To:        Jason Evans <jasone@canonware.com>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: Adding alternate entry points to libc (was Re: Possible libc changes to support LinuxThreads)
Message-ID:  <20000111124932.E360@tar.com>
In-Reply-To: <20000111103527.A302@sturm.canonware.com>; from jasone@canonware.com on Tue, Jan 11, 2000 at 10:35:27AM -0800
References:  <19991209003517.E73529@sturm.canonware.com> <19991209064256.B34152@tar.com> <20000111103527.A302@sturm.canonware.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 11, 2000 at 10:35:27AM -0800, Jason Evans wrote:

> I'm working on adding alternate entry points to libc now.

Good.

> The naming
> approach I'm taking is:
> 
> fwrite()       <-- Alternate entry point that is used externally unless
>                    another library overrides it.
> _libc_fwrite() <-- `_libc_' prefix.  Alternate entry point for internal
>                    library use. 
> __fwrite()     <-- `__' prefix.  Actual name.
> 
> The reason for a prefix of `__' instead of `_' in the actual name case is
> that using only one underscore would be ambiguous at least in the cases of
> setjmp()/_setjmp() and longjmp()/_longjmp().

FYI, the actual name with a single '_' is already defined for syscalls via
SYS.h.  Aliasing '__sycall' to '_syscall' is ok, I assume.  Or, are you planning
on replacing the '_syscall's?  Setjmp/_setjmp are libc calls but not syscalls.
I'm under the impression that linux glibc uses both single and double underscore
symbols, but I don't recall exactly what distinction they make between the two.

> One issue I'm not sure on is whether *every* libc interface should have
> alternate entry points added.  Doing so would be more consistent,

Agreed.

> but it
> probably isn't necessary, since POSIX very clearly defines the set of
> functions that may act as cancellation points.  There end up being a few
> other functions that need wrapped by threads libraries as well.  Of course,
> doing only the necessary ones is easier for me. =)

Agreed its not necessary.  I'm under the impression that linux glibc only
does the "necessary" ones (at lease for the _libc_ prefix), but you'd have
to check the code if you want to be sure, because I'm not.

> If only adding alternate entry points for the necessary libc interfaces,
> there's a good chance I can get this done for 4.0, which will mean
> compliant thread cancellation for both libc_r and linuxthreads.  A genuine
> libpthread is just a hop, skip, and a jump from there.

I'd say only do whats necessary, if thats the case.  Someone really good
with sed, or some other text processor, might be able to semi-automate
the process, but I know I don't know how.

This will be a big help.

-- 
Richard Seaman, Jr.           email: dick@tar.com
5182 N. Maple Lane            phone: 262-367-5450
Chenequa WI 53058             fax:   262-367-5852


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000111124932.E360>