Inlining BEGIN/END_EXCEPTION_HANDLING macros in jni.c (Was: Re: [kaffe] Moving away from macros to inlined functions)

[Dalibor Topic]

Guilhem Lavaux wrote:
> Dalibor Topic wrote:
> 
>> Guilhem Lavaux wrote:
>>
>>> Dalibor Topic wrote:
>>>
>>>> Hi,
>>>>
>>>> this is a simple code hygene issue: I'd like to move away from using 
>>>> preprocessor macros all over kaffe's C sources, to use inline 
>>>> functions. Since the gdb debugger has a much better time with 
>>>> inlines, the gcc compiler produces more useful error and warning 
>>>> messages, inlines can be prototyped to check for type violations, 
>>>> and so on.
>>>>
>>>> I'd like to start with BEGIN/END_EXCEPTION_HANDLING in jni.c and the 
>>>> sysdepCallMethod on arm, as that's what I'm trying to debug at the 
>>>> moment. Is everyone O.K. with the idea to move away from macros?
>>>>
>>>> cheers,
>>>> dalibor topic
>>>
>>>
>>>
>>>
>>> As far as it doesn't complicate kaffe's structure I don't see why we 
>>> should keep them. By the way, introducing true function calls helps 
>>> the programmers to keep a clean way to program. Usually macros are 
>>> bad used... So this should be done at a time or another. I am for it.
>>
>>
>>
>> Seems that it not always easy to do without crashing kaffe badly. I 
>> tried my luck with the BEGIN/END_EXCEPTION_HANDLING macros in jni.c 
>> but I got only crashes during regression tests while compiling the tests:
>>
> Have you tried to run kaffe with just the patch on 
> BEGIN/END_EXCEPTION_HANDLING macros (without touching the rest) ? I fear 
> that FIRSTFRAME is incompatible with using subfunctions as it calls 
> __builting_frame_address(0) (I don't know the syntax but it's a call to 
> gcc on ix86). If __builtin_frame_address returns the pointer to the end 
> of the __current__ function it means that if an exception is thrown it 
> will go to the end of the inlined subfunction and not of the calling 
> function.

Actually, I tried it on arm-linux but it kept getting the same crash as 
before, without the patch. then I took just the jni.c changes and built 
them under i386-linux (which uses the gcc builtin function). As I said, 
it works when installed, but crashes when run from the TestScript. This 
is mildly weird, and I'd expect more consistent failures ;)

I'll try building kaffe with gcc 3.2 instead of 2.95 to see if that 
works better.

cheers,
dalibor topic