Re: [patch] Only build personality routine for SymbianOS.

[Mark Mitchell <mark at codesourcery dot com>]

Benjamin Kosnik wrote:
>>The problem is that for eh_personality.cc we really do want to share
>>most of the code.  
> 
> 
> Not convinced. Lines 90-315 are all arm, IMHO the personality function
> could be better modularized with hooks for sjlj_exceptions,
> callframe_exceptions, and arm_exceptions. I think there is a better way
> to do this than you are proposing.
> 
> Sorry I'm vague on the details.
>
> I feel like if it's left for cleanup, it will never happen. 

In that case, let's see if we can get less vague on the details, since
it's not going to be much fun to restructure all this code in one
direction, only to find out that direction wasn't the one you wanted.

I think the bar is being set pretty high here, in that Paul's patch only
adds a few lines to configure.ac and Makefile.am, and you're asking for
restructing of the actual C++ code in the process.  That said, I'm all
for making the code cleaner.  And like you, I'm disappointed that we now
have to have two versions of the allegedly generic C++ ABI.  We
implemented the ARM bits because that was necessary, not because it was
fun. :-)

I think the first key choice is how much code we want to share.  The
last time around, we worked hard to make sure that most of
PERSONALITY_FUNCTION could be shared between the ARM and generic ABIs.
If we eliminate that sharing, we can easily move the ARM code to a
separate file, as you suggest.  However, we then have all the usual
problems with duplicate code.  So, I think we should try to keep the
sharing.

One way to do that would be to put PERSONALITY_FUNCTION itself in a
header, as a macro, with internal macro calls corresponding to the
places that are now #ifdef'd, like.

  #define PERSONALITY_FUNCTION \
    PERSONALITY_PROTOTYPE
    {
       enum found_handler_type
       ...
       bool foreign_exception;

       PERSONALITY_PROLOGUE

       ...
     }

Then, arm_eh.cc would #include that file, after defining
PERSONALITY_PROLOGUE.  This has the advantage of modularizing the ARM
stuff all in one place, but it's relatively ugly due to the preprocessing.

We could try to use inline function calls, in lie of internal macro
calls (i.e., call "personality_prologue()" instead of
PERSONALITY_PROLOGUE), but that's going to be ugly too; the inline
function calls are going to have to pass many of the local variables in
the personality routine by reference to the inline functions; the ARM
functions use one set of local variables, while other functions use
others.  For example, near the bottom there's a block where the ARM code
uses "ue_header" while the generic code uses "xh" and "context".  So, we
have to do "personality_x (ue_header, xh, context)" so the callee can
twiddle whichever variables are relevant.

Even for, say, vec.cc, I'm a little concerned about moving these
routines into a separate file.  Since the __aeabi routines are such
lightweight wrappers, the compiler might elect to inline the __cxa_
routines into their callers.  But, if we move the ARM routines in vec.cc
to vec_arm.cc, that won't happen -- unless we also move the vec.cc
routines into a header somewhere that can be included.  Or, I guess
vec_arm.cc could #include vec.cc?  Then, vec.cc would have to be in
host_sources for most hosts, while for ARM hosts, it would be vec_arm.cc
instead.

I guess I'm at a loss as to how best to proceed here.  I'm not sure what
change to make that will meet the requirements.

Thoughts?

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713