[PATCH][ARM] Fix RVCT interoperation issue

[PATCH][ARM] Fix RVCT interoperation issue

[Andrew Stubbs]

[-- Attachment #1: Type: text/plain, Size: 265 bytes --]

The attached patch, submitted on behalf of Dan Jacobowitz, fixes an 
unwind bug when using RealView and libgcc.

It's an old patch that has been in CodeSourcery and Linaro toolchains 
for sometime, but somehow escaped being posted here.

OK? (For stage 1?)

Andrew

[-- Attachment #2: rvct-interop.patch --]
[-- Type: text/x-patch, Size: 803 bytes --]

2008-09-08  Daniel Jacobowitz  <dan@codesourcery.com>

	gcc/
	* config/arm/unwind-arm.c (__gnu_unwind_pr_common): Correct test
	for barrier handlers.

--- a/gcc/config/arm/unwind-arm.c
+++ b/gcc/config/arm/unwind-arm.c
@@ -1196,8 +1196,6 @@ __gnu_unwind_pr_common (_Unwind_State state,
 		  ucbp->barrier_cache.bitpattern[4] = (_uw) &data[1];
 
 		  if (data[0] & uint32_highbit)
-		    phase2_call_unexpected_after_unwind = 1;
-		  else
 		    {
 		      data += rtti_count + 1;
 		      /* Setup for entry to the handler.  */
@@ -1207,6 +1205,8 @@ __gnu_unwind_pr_common (_Unwind_State state,
 		      _Unwind_SetGR (context, 0, (_uw) ucbp);
 		      return _URC_INSTALL_CONTEXT;
 		    }
+		  else
+		    phase2_call_unexpected_after_unwind = 1;
 		}
 	      if (data[0] & uint32_highbit)
 		data++;

Re: [PATCH][ARM] Fix RVCT interoperation issue

[Ramana Radhakrishnan]

On Fri, 2011-03-04 at 11:23 +0000, Andrew Stubbs wrote:
> The attached patch, submitted on behalf of Dan Jacobowitz, fixes an 
> unwind bug when using RealView and libgcc.
> 
> It's an old patch that has been in CodeSourcery and Linaro toolchains 
> for sometime, but somehow escaped being posted here.

I would like to see some context around this patch before accepting or
rejecting this, maybe a testcase (agreed that this is harder) or a
description of the problem this patch is attempting to fix. 

cheers
Ramana
-- 

Re: [PATCH][ARM] Fix RVCT interoperation issue

[Andrew Stubbs]

On 09/03/11 16:12, Ramana Radhakrishnan wrote:
> On Fri, 2011-03-04 at 11:23 +0000, Andrew Stubbs wrote:
>> The attached patch, submitted on behalf of Dan Jacobowitz, fixes an
>> unwind bug when using RealView and libgcc.
>>
>> It's an old patch that has been in CodeSourcery and Linaro toolchains
>> for sometime, but somehow escaped being posted here.
>
> I would like to see some context around this patch before accepting or
> rejecting this, maybe a testcase (agreed that this is harder) or a
> description of the problem this patch is attempting to fix.

A testcase would be difficult. GCC won't produce anything that will 
exercise this code. We'd have to cook something up in hand-coded 
assembler, or maybe import something from RVCT - I don't know.

However, the logic can easily be compared with the ARM EHABI document, 
section 9.2:
 
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf

The key sentences are:

  "If the high bit is set in the word containing N, then the type_info
   list is followed by a prel31 landing pad offset (with bit 31 clear)
   to be entered in the event that no type matches the thrown type. High
   bit clear in the N word signifies that implicitly the no match case
   should result in a call to __cxa_call_unexpected. When the high bit
   clear format is used, object producers must emit an R_ARM_NONE
   relocation to __cxa_call_unexpected to indicate the dependency to the
   linker."

(Thanks to Paul Brook for explaining this to me. :)

Andrew

Re: [PATCH][ARM] Fix RVCT interoperation issue

[Ramana Radhakrishnan]

On 11/03/11 17:21, Andrew Stubbs wrote:
> On 09/03/11 16:12, Ramana Radhakrishnan wrote:
>> On Fri, 2011-03-04 at 11:23 +0000, Andrew Stubbs wrote:
>>> The attached patch, submitted on behalf of Dan Jacobowitz, fixes an
>>> unwind bug when using RealView and libgcc.
>>>
>>> It's an old patch that has been in CodeSourcery and Linaro toolchains
>>> for sometime, but somehow escaped being posted here.
>>
>> I would like to see some context around this patch before accepting or
>> rejecting this, maybe a testcase (agreed that this is harder) or a
>> description of the problem this patch is attempting to fix.
>
> A testcase would be difficult. GCC won't produce anything that will
> exercise this code. We'd have to cook something up in hand-coded
> assembler, or maybe import something from RVCT - I don't know.
>
> However, the logic can easily be compared with the ARM EHABI document,
> section 9.2:
>
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf
>
>
> The key sentences are:
>
> "If the high bit is set in the word containing N, then the type_info
> list is followed by a prel31 landing pad offset (with bit 31 clear)
> to be entered in the event that no type matches the thrown type. High
> bit clear in the N word signifies that implicitly the no match case
> should result in a call to __cxa_call_unexpected. When the high bit
> clear format is used, object producers must emit an R_ARM_NONE
> relocation to __cxa_call_unexpected to indicate the dependency to the
> linker."

This is OK for trunk.

cheers
Ramana

Re: [PATCH][ARM] Fix RVCT interoperation issue

[Andrew Stubbs]

On 14/03/11 21:21, Ramana Radhakrishnan wrote:
> This is OK for trunk.

Committed, thanks.

Andrew