This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [arm] Use EABI unwind library


>There are a few more tweaks needed for full conformance, but these patches 
>contain the bulk of the changes.

Any chance you could detail the extent of the remaining work?

You've alluded to changing the arm ABI for linux systems for gcc-4.0.0
in past emails. Is this the plan? Is it a feature? Can you please
document this, if it is indeed the case? If you do this (and the arm
maintainer consents) you'll have to change ligbcc so's, or otherwise
alert users who are expecting gcc-3.4.x and gcc-4.0.0 compatibility. Any
thoughts on this?

>The main conceptual difference between the ia64/dwarf2 unwinder and the arm 
>eabi unwinder is that with the ia64 unwinder all frame unwinding is done 
>under control of the unwind library. With the arm unwinder the actual frame 
>unwinding is done by the language specific personality routine.
>
>The ARM EABI defines personality routines and langage specific data areas for 
>handling C++ exceptions. However these do not fit with the algorithms 
>currently used to identify exception regions. The arm scheme uses multiple 
>overlapping regions with one action per region. The gcc scheme uses discrete 
>recuions with multiple actions per region. This leaves two options:
>a) Rewrite chunks of gcc/except.c
>b) Provide a custom personality routine that uses tables similar to teh 
>existing dwarf2 unwinder.
>
>I chose option (b) to avoid having two different versions of what looks like 
>fairly hairy code, four after it's been backported to 3.4 for CodeSourcery 
>customers.

I would like to hear what RTH and or Jason say about this.

>The libstdc++ code ended up with a few more #ifdefs that I'd like. However the 
>only alternative I see is to duplicate the whole libsupc++/eh_personality.cc, 
>which seems worse.

I have no substantive problem with the libstdc++ patches. It would be
nice if new additions to libsupc++ were consistently formatted with
C++STYLE guidelines for C++ code.

>N.B. This patch requires as-yet unapplied binutils patches for EABI unwind 
>table generation.

It's stuff like this, and the "tweaks" bit above that make me leery of
this for mainline, regardless of the thought that this is certainly an
innovative interpretation of Stage 3. Although this is closer, it still
doesn't seem like you are all the way there...

best,
benjamin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]