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@xxxxxxxxxxx> -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
