On Thu, Sep 11, 2003 at 11:18:44AM -0400, John Dennis wrote:
>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.
b) is only necessary when required by a).
What's the difference between this in the core executable:
xf86A(pointer data)
{
return A(data);
}
SYMFUNC(xf86A)
and this:
SYMFUNCALIAS(xf86A, A)
when data is opaque to both the module and the core executable, and
interpreted only by A() in the system-provided library that the core
executable is linked against?
That the data is opaque to the module isn't true in most cases, hence the
wrapping. It's possible we wrap more functions than is strictly necessary.
>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.
Module independence comes from providing a more uniform ABI to the
modules than you might get by linking directly with the functions provided
by the system libraries. It also comes from having a loader that can
handle different object formats.
>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
Yes.
>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.
That it's directly linked makes no difference. The size of jmp_buf is
determined when the module is compiled. It needs to be large enough for
all the host systems it might run on, since that's where it gets used.
Taking the size of jmp_buf from the module system's headers doesn't
guarantee that.
I'll grant that what we're going with setjmp is a little hairy, but I
haven't seen anything so far that says the basic approach doesn't work
or impacts the portability of modules.
>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.
See my example above.
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
