Inlining BEGIN/END_EXCEPTION_HANDLING macros in jni.c (Was: Re: [kaffe] Moving away from macros to inlined functions)
guilhem at kaffe.org
Sun Sep 21 10:08:02 PDT 2003
Dalibor Topic wrote:
> Guilhem Lavaux wrote:
>> Dalibor Topic wrote:
>>> 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?
>>> 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
It's just a guess...
More information about the kaffe