SIGNAL_ARGS vs EXCEPTIONFRAME (Was: Re: [kaffe] Kaffe 1.1.1 "Development" Release available for download)

[Dalibor Topic]

Hi all,

Dalibor Topic wrote:
> Hi Kiyo,
> 
> Kiyo Inaba wrote:
> 
>> Hi,
>>
>> One more problem.
>> Except for alpha-linux, i386-freebsd, i386-linux, ia64-linux, and
>> s390-linux, interrupt in 'kaffe/kaffevm/systems/unix-jthreads/jthread.h'
>> can not be compiled. Because this function has its argument definition
>> by using macro 'SIGNAL_ARGS(sig,sc)' and default def for this it
>> 'int sig' and sc is not defined in this case. But this variable
>> is used to 'EXCEPTIONFRAME' macro.
> 
> 
> thanks for the bug anaysis, Milos also told me that was the reason why 
> kaffe 1.1.1 doesn't build on NetBSD. The EXCEPTIONFRAME macro call in 
> jthread.c has been introduced in the JVMPI patch. It has only been used 
> before in the signal.c files of threading subsystem implementations, and 
>  it is defined away there for the interpreter case.

We fixed i386-netbsd by copying the definitions over from i386-freebsd2. 
That's hardly going to work for the other 50+ platforms, so we may need 
something more general ;)

The SIGNAL_ARGS macro and its friends came from the xprofiler 
implementation. I though that the current breakage could be fixed by 
defining a GET_SIGNAL_ARGS_CONTEXT macro to 0 when sc in SIGNAL_ARGS is 
defined away and using that to access sc in EXCPETIONFRAME. That doesn't 
work, since EXCEPTIONFRAME implementations rely on reading values out of 
sc. Dereferencing a 0 is a sure way to crash.

So it seems to be best if we could get rid of the EXCEPTIONFRAME call in 
jthread.c ;)

cheers,
dalibor topic