[M3devel] New setjmp/longjmp problem.

[Tony Hosking]

Did you build with -DPTHREAD specified as an argument to cm3 when  
building m3core?

On Jan 11, 2007, at 9:11 PM, Rodney M. Bates wrote:

> How do I tell?
>
> Tony Hosking wrote:
>> Is this with PTHREAD threading or POSIX?
>> On Jan 11, 2007, at 5:40 PM, Rodney M. Bates wrote:
>>> On Mandriva 2007.0, LINUXLIBC6, all dynamically linked  
>>> executables  produced by
>>> either the CM3 or PM3 compilers segfault during initialization  
>>> of  the runtime.
>>> The problem  occurs in longjmp.  There is a replacement for  
>>> setjmp  in the cm3
>>> distribution with this comment:
>>>
>>> #
>>> # Setjmp, _setjmp, and __setjmp are broken in glibc 2.0.7.
>>> # They share code with sigsetjmp which needs 2 arguments, and
>>> # this does not work well on the i386 where the caller must
>>> # pop the stack for the arguments when the call returns.
>>> # Indeed, their setjmp adds the missing argument and jumps to
>>> # sigsetjmp. Upon return, however, the caller pops one argument
>>> # and the second argument remains on the stack, making the stack
>>> # pointer 4 bytes away from its correct position.
>>> #
>>> # Below is a very simple reimplementation of _setjmp, the only   
>>> function
>>> # used within the Modula-3 runtime.
>>> #
>>>
>>> The setjmp in glibc contains the line:
>>>
>>>     xor    %gs:0x18,%ecx
>>>
>>> at two places where the stack pointer and the return address are  
>>> in  %ecx.  The
>>> replacement just stores these registers in the jmpbuf without   
>>> molesting them.
>>> Up at least through libc-2.3.4 (where this problem does not  
>>> occur),  longjmp
>>> just reloads the stack and instruction pointers from the  
>>> jmpbuf.   This does not
>>> sound like the problem the comment identifies, but it clearly is   
>>> inconsistent
>>> and would cause the setjmp/longjmp pair to fail.
>>>
>>> As of libc-2.4, the original brokenness of setjmp seems to have   
>>> been fixed by
>>> doing the very same xor operations to these values when  
>>> reloading  them from
>>> the jmpbuf, in longjmp.  The fault occurs inside RTThreadC.c,   
>>> function Transfer,
>>> which calls setjmp and immediately passes the result to  
>>> longjmp.   Removing the
>>> replacement for setjmp and recompiling so that both setjmp and   
>>> longjmp come from
>>> libc makes this segfault go away.
>>>
>>> Unfortunately, this just causes another segfault almost  
>>> immediately  after,
>>> when M3 runtime code attempts to use the contents of these   
>>> registers from
>>> a jmpbuf, supplied by a different call on setjmp, where the  
>>> values  are now
>>> garbled by the original xor problem with setjmp.
>>>
>>> I am looking for suggestions on what to do.  Possibilities that   
>>> have occurred
>>> to me:
>>>
>>> 1.  Also add an assembly code replacement for longjmp too, taken   
>>> from an earlier
>>>     libc.  longjmp is quite a bit longer, and does some tricky   
>>> stuff I have not
>>>     dug through yet.
>>>
>>> 2.  Use the libc setjmp for values that are to be passed to  
>>> longjmp  and use the
>>>     replacement setjmp for values that are to be used by the M3   
>>> runtime.  This
>>>     seems cleaner in the long run, but a preliminary grep  
>>> reveals  massive numbers
>>>     of hits on "setjmp".  I had been hoping there would only be  
>>> a  few.  The two
>>>     uses of jmpbuf values may not even be disjoint.
>>>
>>> This will probably affect other distributions as they go to  
>>> later  libc versions.
>>> Any suggestions would be appreciated.
>>>
>>> P.S:  I had some cases where changing the M3 compilation to link   
>>> statically made
>>> the problem go away, but now I can't reproduce them.  Instead,  
>>> bash  and ldd claim
>>> "executable: No such file or directory", while "ls -l  
>>> executable"  and many other
>>> commands find "executable" just fine.
>>>
>>>
>>> -- 
>>> -------------------------------------------------------------
>>> Rodney M. Bates, retired assistant professor
>>> Dept. of Computer Science, Wichita State University
>>> Wichita, KS 67260-0083
>>> 316-978-3922
>>> rodney.bates at wichita.edu
>>> _______________________________________________
>>> M3devel mailing list
>>> M3devel at elegosoft.com
>>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>> Antony Hosking                | Associate Professor
>> Dept of Computer Science      | Office: +1 765 494-6001
>> Purdue University             | Mobile: +1 765 427-5484
>> 250 N. University Street      | Email:  hosking at cs.purdue.edu
>> West Lafayette, IN 47907-2066 | http://www.cs.purdue.edu/~hosking
>>  _--_|\
>> /      \
>> \_.--._/    )
>>       v    /
>
> -- 
> -------------------------------------------------------------
> Rodney M. Bates, retired assistant professor
> Dept. of Computer Science, Wichita State University
> Wichita, KS 67260-0083
> 316-978-3922
> rodney.bates at wichita.edu

Antony Hosking                | Associate Professor
Dept of Computer Science      | Office: +1 765 494-6001
Purdue University             | Mobile: +1 765 427-5484
250 N. University Street      | Email:  hosking at cs.purdue.edu
West Lafayette, IN 47907-2066 | http://www.cs.purdue.edu/~hosking
  _--_|\
/      \
\_.--._/    )
       v    /