This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.

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

Versioning longjmp etc.

From: Steve Munroe <sjmunroe at us dot ibm dot com>
To: libc-hacker at sources dot redhat dot com
Cc: sjmunroe at vnet dot ibm dot com
Date: Fri, 17 Oct 2003 15:47:03 -0500
Subject: Versioning longjmp etc.

We are looking at integrating Vector Extensions (AKA Altivec or VMX) into 
glibc for PPC32/PPC64. This will change the size of __jmp_buf and 
sigcontext/ucontext and requires versioning of the corresponding functions 
(setjmp/longjmp etc). 

I assume this includes the complete function stack, for example 
[siglongjmp | longjmp] -> [__libc_siglongjmp | __libc_longjmp] -> 
__longjmp.

But looking at linuxthreads/ptlongjmp.c and nptl/pt-longjmp.c I don't 
understand why we need the siglongjmp()/longjmp() stubs. They add 
path-length without adding any function (at least in the current 
implementation). 

So could these stubs be eliminated and replaced with aliases? If they are 
required where should I move ptlongjmp.c to (sysdeps/pthreads, 
sysdeps/generic, ...) so I can override it for powerpc[32 | 64]? Or should 
the siglongjmp()/longjmp() stubs be split out of ptlongjmp.c?

Follow-Ups:
- Re: Versioning longjmp etc.
  - From: Ulrich Drepper

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