On Thu, Sep 11, 2003 at 05:24:40PM -0400, John Dennis wrote:
>On Thu, 2003-09-11 at 14:35, David Dawes wrote:
>> What's the difference between this in the core executable:
>>
>> xf86A(pointer data)
>> {
>> return A(data);
>> }
>>
>> SYMFUNC(xf86A)
>>
>> and this:
>>
>> SYMFUNCALIAS(xf86A, A)
>
>The difference is that xf86A may massage "data" in some system specific
>manner specific to the libraries the main executable is linked against.
You left out that I said "when data is opaque to both the module and
the core executable". Why?
>O.K. I'll make this patch and put it in the bugzilla. I'm not completely
>happy with it because its not really addressing the root problem. Setjmp
>may "blow up" on some other system in the future because we're ignoring
>the system defined requirements. For example in the non-ia64 case
>xf86jmp_buf will only be aligned on int boundaries, what if a system
>needs long alignment, or some other requirement?
When that happens we'll fix it. If we want to be more defensive against
such possibilities, we can try using stronger alignment on all platforms
where the compiler supports it.
>libc version 1.0 requires 8 byte alignment, server XFree86 A is linked
>against this library.
>
>libc version 1.1 requires 16 byte alignment, server XFree86 B is linked
>against this library.
>
>The module in "theory" can be loaded into either XFree86 server A or B.
>If the module was built against the libc 1.0 requirement it will fail
>when loaded into XFree86 B. This is because unlike the system loader
Yes, if the size of jmp_buf or its alignment aren't sufficient, it will
be a problem. We've been fixing the bugs in this as they are found.
We knew of the size issue, but the extra alignment issue didn't occur
to us. If it had been tested on IA64 before 4.3 we'd probably have
found the problem and fixed it then. I did specifically test the setjmp
behaviour for correctness on the platforms I have access too, but
unfortunately IA64 isn't one of them.
>which enforces the right version of the library to be loaded when
>XFree86 is loaded by the system, the module loader does not deal with
>version dependencies. In part because the version dependencies in theory
>have been isolated in the main executable image via wrappers and
>enforced by the system loader. The current setjmp implementation
>violates all these assumptions which is why I conclude this negatively
>impacts module portability. It is also true that if setjmp were in a
Bugs or limitations in our implementation impact module portability,
yes. setjmp() isn't the first place we've had a portability problem
because of a bug or limitation in an implementation. So far nobody has
given a reason why this approach must be inherently not portable, but
only correctable limitations in the implmentation that have led to
problems. That what testing is for.
>Granted, if we are lucky this may never bite us, there is a reasonable
>chance it won't, but on the other hand to assert we haven't lost module
>independence and portability is not being honest about the new situation
>with modules that import xf86set_jmp.
>
>I'm not saying I have an answer to the problem we've created for
>ourselves, but I am saying we need to be honest about the impact, that
>any module that imports xf86set_jmp is no longer portable, is tied the
>libraries the main XFree86 is linked against, and as such we might as
>well use the system definitions of jmp_buf because its the robust
>solution and is no more, no less portable than inventing a jmp_buf
>abstraction that inherently is not robust. So if you're not getting
>portability and independence with the abstraction why sacrifice
>robustness?
I obviously disagree with your take on the situation. You've found a
bug, lets fix it, test it as widely as possible, and move on. The
"portability" issues you're raising here are hypothetical rather than
real reported cases. The problem you found was on IA64. That wasn't
specifically a module portability issue. It was the fact that our
setjmp is currently plain broken on IA64.
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
