adapting to new setjmp/longjmp implementation

[Nicholas Miell]

On Mon, 2006-09-18 at 13:08 -0700, John Reiser wrote:
> >> Fix your application.
> > 
> > 
> > Thanks for your help.
> 
> Yes, it is a pain, but at least it is fast and simple
> (else you could complain because of performance degradation.)
> Detect the glibc version, or look directly at the code at run time,
> then compensate.
> 
> 0x4c4a8ba0 <__longjmp>: mov    0x4(%esp),%eax
> 0x4c4a8ba4 <__longjmp+4>:       mov    0x14(%eax),%edx
> 0x4c4a8ba7 <__longjmp+7>:       mov    0x10(%eax),%ecx
> 0x4c4a8baa <__longjmp+10>:      xor    %gs:0x18,%edx
> 0x4c4a8bb1 <__longjmp+17>:      xor    %gs:0x18,%ecx
> 0x4c4a8bb8 <__longjmp+24>:      mov    (%eax),%ebx
> 0x4c4a8bba <__longjmp+26>:      mov    0x4(%eax),%esi
> 0x4c4a8bbd <__longjmp+29>:      mov    0x8(%eax),%edi
> 0x4c4a8bc0 <__longjmp+32>:      mov    0xc(%eax),%ebp
> 0x4c4a8bc3 <__longjmp+35>:      mov    0x8(%esp),%eax
> 0x4c4a8bc7 <__longjmp+39>:      mov    %ecx,%esp
> 0x4c4a8bc9 <__longjmp+41>:      jmp    *%edx
> 
> Then, petition the standards committee for the logical functionality
> that you find useful.  Your long-standing usage will satisfy one of the
> major check boxes in the process.

It already exists, in the form of the ucontext functions -- despite
their inability to actually work with an arbitrary or kernel-generated
ucontext_t, they should still be perfectly serviceable for most user
usage cases.

-- 
Nicholas Miell <nmiell at comcast.net>