Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 9 Dec 1999 12:57:45 -0800
From:      Jason Evans <jasone@canonware.com>
To:        "Richard Seaman, Jr." <dick@tar.com>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: Possible libc changes to support LinuxThreads
Message-ID:  <19991209125745.G73529@sturm.canonware.com>
In-Reply-To: <19991209064256.B34152@tar.com>; from dick@tar.com on Thu, Dec 09, 1999 at 06:42:56AM -0600
References:  <19991209003517.E73529@sturm.canonware.com> <19991209064256.B34152@tar.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote:
> On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote:
> 
> The problem with cancellation points, libc and linuxthreads has been
> that you need to wade through libc and replace instances of, for 
> example, write() with either _write() or _libc_write() in order to
> avoid propagating cancellation points where they don't belong.

Now I understand why you claimed that making cancellation work is a lot of
work.  Since that isn't currently done, do you think it would be better to
leave broken cancellation in the LinuxThreads port, or to take it out?  As
things stand right now, "broken" means:

1) Not all mandatory cancellation points are implemented.
2) Some functions may act as cancellation points, even though they
   shouldn't.

We can fix 1) with some symbol munging, but 2) is much more difficult, as
you point out.

> > The other issue has to do with longjmp() and siglongjmp(), and is of a
> > similar nature, except that _longjmp() already exists as a separate
> > interface.  So, at least in the case of longjmp(), it needs to have a
> > different alias, perhaps __longjmp().  Below is a *very* simplistic patch
> > to libc that works, but it may make some people's skin crawl.  Feedback is
> > welcome.  If there is no correct way to create aliases to function entry
> > points, then we can do without them, but it will mean that the *jmp()
> > functions cannot be used in conjunction with thread cleanup handlers when
> > using LinuxThreads.
> 
> __longjmp() and __siglongjmp() don't bother me at all.

Following is a slightly better patch that uses weak aliases.  longjmp()
must be an alias for __longjmp() since _longjmp() is a public interface.
However, siglongjmp() could be an alias for either _siglongjmp() or
__siglongjmp().  Is _siglongjmp() more consistent?

Of course, this doesn't matter at all if we leave out cancellation
entirely.

Index: i386/gen/setjmp.S
===================================================================
RCS file: /home/ncvs/src/lib/libc/i386/gen/setjmp.S,v
retrieving revision 1.11
diff -u -r1.11 setjmp.S
--- setjmp.S	1999/10/10 08:38:33	1.11
+++ setjmp.S	1999/12/09 20:53:11
@@ -54,7 +54,9 @@
 #include "DEFS.h"
 #include "SYS.h"
 
-ENTRY(setjmp)
+ENTRY(__setjmp)
+.weak setjmp;
+.set setjmp, __setjmp;
 	movl	4(%esp),%ecx
 	PIC_PROLOGUE
 	leal	28(%ecx), %eax
@@ -80,7 +82,9 @@
 	xorl	%eax,%eax
 	ret
 
-ENTRY(longjmp)
+ENTRY(__longjmp)
+.weak longjmp;
+.set longjmp, __longjmp;
 	movl	4(%esp),%edx
 	PIC_PROLOGUE
 	pushl	$0			/* (sigset_t*)oset */
Index: i386/gen/sigsetjmp.S
===================================================================
RCS file: /home/ncvs/src/lib/libc/i386/gen/sigsetjmp.S,v
retrieving revision 1.13
diff -u -r1.13 sigsetjmp.S
--- sigsetjmp.S	1999/09/29 15:18:35	1.13
+++ sigsetjmp.S	1999/12/09 20:53:11
@@ -59,7 +59,9 @@
  *	use sigreturn() if sigreturn() works.
  */
 
-ENTRY(sigsetjmp)
+ENTRY(__sigsetjmp)
+.weak sigsetjmp;
+.set sigsetjmp, __sigsetjmp;
 	movl	8(%esp),%eax
 	movl	4(%esp),%ecx
 	movl	%eax,44(%ecx)
@@ -89,7 +91,9 @@
 	xorl	%eax,%eax
 	ret
 
-ENTRY(siglongjmp)
+ENTRY(__siglongjmp)
+.weak siglongjmp;
+.set siglongjmp, __siglongjmp;
 	movl	4(%esp),%edx
 	cmpl	$0,44(%edx)
 	jz	2f


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?19991209125745.G73529>