[patch] Only build personality routine for SymbianOS.

Mark Mitchell mark@codesourcery.com
Tue Jan 24 00:23:00 GMT 2006


Benjamin Kosnik wrote:
>>Benjamin, have you had a chance to look at this?
> 
> 
> Thanks for your patience. I was able to look at this today.

Thanks for taking the time to look into it.  (For the record, I too wish
that this stuff were not necessary.)

> For some time I've been thinking that there is a better way to organize libsupc++ for the various arm twisting....  I would like a cleaner separation between the arm extra bits and the rest of the stuff that is used by everybody. It seems like the arm-specific runtime bits have been growing in an ad-hoc manner, and at this time it's sufficiently large that it deserves a bit more thought.
> 
> One way to do this would be to use something like host_sources and move the _ARM_EABI_UNWINDER bits as follows:
> 
> eh_arm as is
> eh_call -> eh_call_arm
> eh_personality -> eh_personality_arm
> vec.cc -> vec_arm.cc

The problem is that for eh_personality.cc we really do want to share
most of the code.  So, you'd have to break PERSONALITY_FUNCTION into
macroized chunks, or something, to separate it this way.  Also, since we
need a different __cxa_call_unexpected, not just an additional function,
we still need some way to turn off the version in eh_personality.cc.  If
we put that function in a separate file, to avoid #ifdefs, then we just
be adding $(host_sources); we'd have to have $(host_eh_files) with
defaults for most systems, and a different, partially overlapping, set
for ARM.

> Anyway. I think this will allow a bit more granularity for the symbian
> config (which is different or a subset of __arm__ and __ARM_EABI__ and
> __ARM_EABI_UNWINDER, eh? I don't fully understand the varoius
> permutations. Does symbian arm define _ARM_EABI_UNWINDER, but unlike
> arm-elf, it only needs the personality routines?)

Correct, because the unwinder logic itself is provided in a system library.

> 1) LIBSUPCXX_PRONLY should be LIBSUPCXX_PERSONALITY_ONLY
> 2) edit Makefile.am not include/Makefile.am to not install the include files
> 3) with the changes above, you can use host_sources to do the libsupc++/Makefile.am bits

I've leave it to you and Paul to agree on a particular plan.  Is 3) as a
pre-checkin requirement, or is that something that could be done as a
subsequent cleanup?

Thanks,

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



More information about the Libstdc++ mailing list