I have found the problem with XFree86's implementation of setjmp on
ia64. It occurs because we are ignoring the type definition of
setjmp's argument.
int setjmp(jmp_buf env);
In xf86_lib.h we redefine jmp_buf thusly:
/* setjmp/longjmp */
typedef int xf86jmp_buf[1024];
#undef jmp_buf
#define jmp_buf xf86jmp_buf
Based on the discussions that occurred last Feb and March I believe
this was done to preserve a loadable modules system independence. The
notion being that each system may have a different jmp_buf size, we
can't know aprori what that is, so make it bigger than we think is
necessary and it should be big enough no matter on what system the
module is loaded on.
However ignoring the system defined type for jmp_buf we've ignored the
system specific alignment requirement of jmp_buf. On ia64 it must be
16 byte aligned because setjmp when it saves the execution context on
ia64 uses machine instructions that writes the contents of the 16 byte
floating point registers, the destination address must be 16 byte
aligned or a SIGBUS fault is signaled.
On ia64 you can see in /usr/include/bits/setjmp.h the following
jmp_buf definition:
/* the __jmp_buf element type should be __float80 per ABI... */
typedef long __jmp_buf[_JBLEN] __attribute__ ((aligned (16))); /*
guarantees 128-bit alignment! */
I did an experiment where I defeated the use of xf86jmp_buf and
instead used the systems definition of jmp_buf and the SIGBUS problem
went away. Earlier I had noted that a static server did not exhibit
the problem, thats because the xf86jmp_buf is only used in a loadable
build.
How do we fix this?
-------------------
1) It may be hard to know the alignment requirements for all OS's and
architectures (thats part of the reason we have system header
files). We could guess 16 byte is sufficient. But even if we got the
alignment requirement right how do we specify the alignment requirement
to the compiler in a portable way such that it will build on a variety
of systems and compilers? My understanding is that compiler alignment
directives are not portable (e.g. not part of ANSI C). Are we
comfortable picking one or two common alignment directives and
conditionally compiling with the right one?
2) We cannot force alignment without the use of compiler directives
for any alignment greater than the maximum size of a basic type by
creating artifical structs. This is because in C structs are aligned
to the size of the maximum basic type, which on ia64 is 8 (long,
double, etc), half the alignment requirement. Plus such a scheme would
put us back into guessing type sizes, alignment requrements, etc. It
would not be robust.
3) We could use the systems's definition of jmp_buf. That means it
will always be correct on the system it was compiled on, but that
module may be loaded on another system with potentially different
jmp_buf definitions and cause problems. I realize we have a goal of
system independence for loadable modules, but do we really expect
modules built on one system to be loaded on a significantly different
system? They are after all binary modules. I also realize that setjmp
is currently the only thing in our loadable modules which is not
wrapped by a core server function so it would kind of be a shame to
let this one item polute module independence but we have no choice,
the loader now links the system implementation of setjmp and not a
wrapper. So as long as we've already lost module independence by
virtue of linking the system function why not go all the way and use
the system definition of the system function's argument? It seems like
we would not have lost anything and would have picked up robustness
we've given up by trying to use a system neutral definition of the
jmp_buf argument.
Given the argument in 3 above I'd recommend taking out xf86jmp_buf and
putting back in #include <stdjmp.h>. It seems the simplist, most
robust, and in practical terms sacrifices little.
Comments?
I'm going to file a bugzilla on this, its very definitely broken on
ia64 and causes the server to crash. I will put the text of this in
the bugzilla.
John
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
