Re: Compile problem with setjmp fix
On Fri, Feb 21, 2003 at 11:55:41AM -0500, David Dawes wrote: On Fri, Feb 21, 2003 at 01:19:08PM +, Dr Andrew C Aitchison wrote: The setjmp/longjmp fix in xc/programs/Xserver/hw/xfree86/loader/xf86sym.c and xc/programs/Xserver/hw/xfree86/xf86cfg/loadmod.c doesn't compile in RedHat 6.2 egcs-2.91.66 It works fine with Red Hat 7.3 gcc 2.96 and Red Hat 8.0 gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) It looks like RH 6.2 and earlier (i.e. glibc before 2.2) uses a macro for setjmp(): extern int __sigsetjmp __P ((jmp_buf __env, int __savemask)); #ifndef __FAVOR_BSD /* Set ENV to the current position and return 0, not saving the signal mask. This is just like `sigsetjmp (ENV, 0)'. The ISO C standard says `setjmp' is a macro. */ # define setjmp(env)__sigsetjmp ((env), 0) #else /* We are in 4.3 BSD-compatibility mode in which `setjmp' saves the signal mask like `sigsetjmp (ENV, 1)'. */ # define setjmp(env)__sigsetjmp ((env), 1) #endif /* Favor BSD. */ Harbison Steele also refers to the macro setjump and the function longjmp. This certainly complicates things. A couple of possibilities: 1. Include setjmp.h directly into modules that need it, ensure that the necessary (platform-specific) entry points are exported, and accept that modules that use it are not OS-neutral. 2. Provide aliases for the actual functions uses on the platforms we support, and come up with a macro for xf86setjmp() that calls the correct one in the correct way, probably by first querying a function in the core server for which way to use. The attached patch attempts to implement the second approach, and from some limited testing it works OK for the two cases handled so far (where setjmp is available directly as a function, and the glibc 2.[01] case where it's a macro defined as above). This approach method isn't always guaranteed to work given the limits that ISO C places on the way setjmp() can be called. Has anyone found any other platforms where setjmp isn't available directly as a function? David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes Index: lib/font/FreeType/ftstdlib.h === RCS file: /home/x-cvs/xc/lib/font/FreeType/ftstdlib.h,v retrieving revision 1.4 diff -u -r1.4 ftstdlib.h --- lib/font/FreeType/ftstdlib.h2002/10/10 01:18:31 1.4 +++ lib/font/FreeType/ftstdlib.h2003/02/21 18:39:01 -58,6 +58,7 #define _XTYPEDEF_BOOL #include Xdefs.h #define DONT_DEFINE_WRAPPERS +#define DEFINE_SETJMP_WRAPPERS #include xf86_ansic.h #undef DONT_DEFINE_WRAPPERS -94,9 +95,9 #define ft_atoi xf86atoi -#define ft_jmp_buf xf86jmp_buf -#define ft_setjmp xf86setjmp -#define ft_longjmp xf86longjmp +#define ft_jmp_buf jmp_buf +#define ft_setjmp setjmp +#define ft_longjmp longjmp #endif /* FONTMODULE */ Index: programs/Xserver/hw/xfree86/loader/xf86sym.c === RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/loader/xf86sym.c,v retrieving revision 1.225 diff -u -r1.225 xf86sym.c --- programs/Xserver/hw/xfree86/loader/xf86sym.c2003/02/21 03:11:57 1.225 +++ programs/Xserver/hw/xfree86/loader/xf86sym.c2003/02/21 21:15:35 -134,6 +134,17 #pragma weak __umodsi3 #endif + +#if defined(setjmp) \ +defined(__GLIBC__) __GLIBC__ == 2 __GLIBC_MINOR__ 2 +#undef setjmp +extern int setjmp(jmp_buf env); +#pragma weak setjmp +#elif !defined(__GLIBC__) +extern int __sigsetjmp(jmp_buf __env, int __savemask); +#pragma weak __sigsetjmp +#endif + #if defined(__arm__) defined(__linux__) #include sys/io.h #endif -889,7 +900,10 SYMFUNC(xf86shmdt) SYMFUNC(xf86shmctl) SYMFUNCALIAS(xf86setjmp,setjmp) + SYMFUNCALIAS(xf86setjmp1,__sigsetjmp) SYMFUNCALIAS(xf86longjmp,longjmp) + SYMFUNC(xf86getjmptype) + SYMFUNC(xf86setjmperror) #ifdef XF86DRI /* These may have more general uses, but for now, they are only used by the DRI. Index: programs/Xserver/hw/xfree86/os-support/xf86_ansic.h === RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/os-support/xf86_ansic.h,v retrieving revision 3.48 diff -u -r3.48 xf86_ansic.h --- programs/Xserver/hw/xfree86/os-support/xf86_ansic.h 2001/12/31 18:13:37 3.48 +++ programs/Xserver/hw/xfree86/os-support/xf86_ansic.h 2003/02/21 21:21:59 -305,8 +305,16 extern char * xf86shmat(int id, char *addr, int xf86shmflg); extern int xf86shmdt(char *addr); extern int xf86shmctl(int id, int xf86cmd, pointer buf); + extern int xf86setjmp(xf86jmp_buf env); +extern int xf86setjmp1(xf86jmp_buf env, int); +extern int xf86setjmperror(xf86jmp_buf env, int); +extern int xf86getjmptype(void); extern void xf86longjmp(xf86jmp_buf env, int
Re: Compile problem with setjmp fix
On Fri, Feb 21, 2003 at 11:00:03AM -0700, Marc Aurele La France wrote: On Fri, 21 Feb 2003, David Dawes wrote: On Fri, Feb 21, 2003 at 01:19:08PM +, Dr Andrew C Aitchison wrote: The setjmp/longjmp fix in xc/programs/Xserver/hw/xfree86/loader/xf86sym.c and xc/programs/Xserver/hw/xfree86/xf86cfg/loadmod.c doesn't compile in RedHat 6.2 egcs-2.91.66 It works fine with Red Hat 7.3 gcc 2.96 and Red Hat 8.0 gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) It looks like RH 6.2 and earlier (i.e. glibc before 2.2) uses a macro for setjmp(): extern int __sigsetjmp __P ((jmp_buf __env, int __savemask)); #ifndef __FAVOR_BSD /* Set ENV to the current position and return 0, not saving the signal mask. This is just like `sigsetjmp (ENV, 0)'. The ISO C standard says `setjmp' is a macro. */ # define setjmp(env)__sigsetjmp ((env), 0) #else /* We are in 4.3 BSD-compatibility mode in which `setjmp' saves the signal mask like `sigsetjmp (ENV, 1)'. */ # define setjmp(env)__sigsetjmp ((env), 1) #endif /* Favor BSD. */ Harbison Steele also refers to the macro setjump and the function longjmp. This certainly complicates things. A couple of possibilities: 1. Include setjmp.h directly into modules that need it, ensure that the necessary (platform-specific) entry points are exported, and accept that modules that use it are not OS-neutral. 2. Provide aliases for the actual functions uses on the platforms we support, and come up with a macro for xf86setjmp() that calls the correct one in the correct way, probably by first querying a function in the core server for which way to use. Just another data point: libGLU compilation on such systems fails also. libGLU builds OK on the RH 6.2 system I've been looking into this with. It does do some things with setjmp (using inlined functions). We don't build libGLU for libc5-based systems, but I don't have access to one (RH 4.2, is one I think -- anyone have a CD image for RH 4.2? I don't see one on RH's ftp site.). David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Compile problem with setjmp fix
On Fri, 21 Feb 2003, David Dawes wrote: 1. Include setjmp.h directly into modules that need it, ensure that the necessary (platform-specific) entry points are exported, and accept that modules that use it are not OS-neutral. 2. Provide aliases for the actual functions uses on the platforms we support, and come up with a macro for xf86setjmp() that calls the correct one in the correct way, probably by first querying a function in the core server for which way to use. Just another data point: libGLU compilation on such systems fails also. libGLU builds OK on the RH 6.2 system I've been looking into this with. It does do some things with setjmp (using inlined functions). We don't build libGLU for libc5-based systems, but I don't have access to one (RH 4.2, is one I think -- anyone have a CD image for RH 4.2? I don't see one on RH's ftp site.). Someone in Raleigh probably has a copy kicking around somewhere. I've got one buried in a box somewhere if nobody else can dig one up more easily. I've got Red Hat Linux 0.1 on ftp://people.redhat.com/mharris/ but I'm not sure that would even boot on anything newer than a i386/i486. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Compile problem with setjmp fix
On Fri, Feb 21, 2003 at 03:35:35PM -0700, Marc Aurele La France wrote:
On Fri, 21 Feb 2003, David Dawes wrote:
The setjmp/longjmp fix in
xc/programs/Xserver/hw/xfree86/loader/xf86sym.c
and xc/programs/Xserver/hw/xfree86/xf86cfg/loadmod.c
doesn't compile in
RedHat 6.2 egcs-2.91.66
It works fine with
Red Hat 7.3 gcc 2.96
and
Red Hat 8.0 gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
It looks like RH 6.2 and earlier (i.e. glibc before 2.2) uses a macro for
setjmp():
extern int __sigsetjmp __P ((jmp_buf __env, int __savemask));
#ifndef __FAVOR_BSD
/* Set ENV to the current position and return 0, not saving the signal mask.
This is just like `sigsetjmp (ENV, 0)'.
The ISO C standard says `setjmp' is a macro. */
# define setjmp(env)__sigsetjmp ((env), 0)
#else
/* We are in 4.3 BSD-compatibility mode in which `setjmp'
saves the signal mask like `sigsetjmp (ENV, 1)'. */
# define setjmp(env)__sigsetjmp ((env), 1)
#endif /* Favor BSD. */
Harbison Steele also refers to the macro setjump and the function
longjmp.
This certainly complicates things.
A couple of possibilities:
1. Include setjmp.h directly into modules that need it, ensure that the
necessary (platform-specific) entry points are exported, and accept that
modules that use it are not OS-neutral.
2. Provide aliases for the actual functions uses on the platforms we support,
and come up with a macro for xf86setjmp() that calls the correct one in
the correct way, probably by first querying a function in the core
server for which way to use.
Just another data point: libGLU compilation on such systems fails also.
libGLU builds OK on the RH 6.2 system I've been looking into this with.
It does do some things with setjmp (using inlined functions).
How? I have been unable to get libGLU to compile on a system that
#define's setjmp friends as macros.
It just works for me on RH 5.2 (glibc 2.0) and RH 6.2 (glibc 2.1) .
It uses inline'd functions:
inline int
mysetjmp( JumpBuffer *j )
{
return ::setjmp( j-buf );
}
Maybe it depends on the g++ version?
I'm not sure why libGLU does this in the libnurbs code. In the libtess
code it just uses setjmp/longjmp directly. (Maybe because the former is
C++ and the latter C?)
David
--
David Dawes
Release Engineer/Architect The XFree86 Project
www.XFree86.org/~dawes
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Compile problem with setjmp fix
On Fri, Feb 21, 2003 at 07:18:37PM -0800, Keith Packard wrote: Around 17 o'clock on Feb 21, David Dawes wrote: The attached patch attempts to implement the second approach, and from some limited testing it works OK for the two cases handled so far (where setjmp is available directly as a function, and the glibc 2.[01] case where it's a macro defined as above). I think you're on the right track -- create a macro which invokes different functions depending on the underlying libc. I think we can do it with smaller changes, and no magic GCC pragmas. See attached. The '#pragma weak' was only used as a short cut. To be more portable, dummy functions that FatalError() would be provided in the case where the incorrect one for the OS gets called. As for the other changes, I opted to keep the xf86setjmp entry point rather than use it as the macro name. Although it probably doesn't matter much, this would allow older modules that use setjmp to work in thoses cases where the old xf86jmp_buf size was large enough. Alternatively, we could admit that this is all very OS dependent and #include stdjmp.h in the application, then all we need do is add SYMFUNC's for the actual underlying function names in xf86sym.c (and not for the ones not present on the system) and things should work as expected. Modules built for another OS would fail to resolve the expected symbol and crash as soon as setjmp was invoked. If we run into cases that can't reasonably be handled, then that's our fallback. So far it looks managable. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
