On Wed, 2003-09-10 at 20:11, David Dawes wrote:
John> wrapper. So as long as we've already lost module
John> independence by virtue of linking the system function why
John> not go all the way and use the system definition of the
John> system function's argument? It seems like
David> We haven't lost module independence by doing that.
Perhaps I'm misunderstanding module independence, can you confirm or
deny some of the assumptions I've been working with:
1) System specific functions are wrapped in an xf86* wrapper so that:
a) system differences are isolated at a single point which provides
a common interface to the rest of the server
b) all system specific functions are wrapped and live in the
executable XFree86. The XFree86 executable is linked against
the system libraries and hence the XFree86 executable is not
system independent.
2) module independence derives from the following:
a) modules only link against (e.g. import) from the XFree86
executable that loaded it. In other words all system
specific elements are contained in the executable, not a
loaded module.
b) The executable and modules share the same linking,
relocation, exception, and call conventions. This makes
a module mostly system independent, but not 100%, e.g.
its possible, but not common, for different OS's on the same
architecture to have a different ABI, but less common today
as the industry is converging on standardized ABI's.
Is the above basically correct?
If so then by directly linking a reference to the system's setjmp call
in a module haven't we violated the notion that only the main
executable has dependencies on the system libraries? The module is now
making a call whose parameters and behavior is specific to the
system. Actually, more correctly, its specific to the how the main
executable was linked (which is system specific), see below for why
this is true.
David> All that matters is that the jmp_buf type be defined on
David> each architecture in such a way that it meets the
David> requirements of all the supported OSs on that architecture.
David> Newer architectures are more likely to have a
David> platform-independent ABI anyway than was necessarily true
David> in the past. If the platform's <setjmp.h> can define the
David> type with the correct alignment, then so can we. It
David> doesn't matter if the methods for doing this are
David> compiler-specific. If the 128-bit alignment is an IA64 ABI
David> requirement, then I'd expect that all complilers for IA64
David> will have a method for defining jmp_buf with the correct
David> alignment.
If I following your reasoning then you would be happy with this
definition in xf86_libc.h
/* setjmp/longjmp */
#if defined(__ia64__)
typedef int xf86jmp_buf[1024]; __attribute__ ((aligned (16))); /* guarantees 128-bit
alignment! */
#else
typedef int xf86jmp_buf[1024];
#endif
But if one is going to special case the definition of jmp_buf based on
architecture why not use the system definition and typedef xf86jmp_buf
to be jmp_buf? I suspect the answer will be that the system libraries
could change requiring a different size buffer. I'd buy that if it
weren't for the fact we are directly linking the library specfic
version of setjmp into the module.
Why a module referencing setjmp is tied to a specific system library:
---------------------------------------------------------------------
As far as I can tell we've tied the module to a specific system
library. Here is why I believe this. I'm going to simplify the
discussion by assming there is only one xf86set_jmp symbol and ignore
the type 0 and type 1 variants that select setjmp or sigsetjmp.
1) a module makes a reference to xf86set_jmp.
2) the xfree86 loader when it loads that module searches for that
symbol in its hash table of symbols, that table was populated in
part by the table in xf86sym.c which in a loadable build contains
this definition in the main executable:
#include <setjmp.h>
SYMFUNCALIAS("xf86setjmp",setjmp)
3) the above definition means when the symbol name "xf86setjmp" is
looked up by the loader it will get the address of setjmp that was
linked into the main executable. This is the function address that
the xfree86 loader will insert into module during its relocation
phase.
4) How does the address of setjmp get into the main executable? It
depends on whether the main executable was statically or
dynamically linked, but in either case the system will assure it
comes from a specific version of the library defined at the time
the main executable was linked.
5) Therefore when a module that referenced setjmp is called its
calling the system version of setjmp in the exact library when the
main executable was linked.
I don't see how the above satisfies the conception of module
independence and by extension the avoidence of using the system
specfic typedef's in force when the main executable was linked.
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
