unwind and type support in GCC47

unwind and type support in GCC47

[Paulo J. Matos]

Hi,

I am porting my backend to GCC47 and have been jumping through some 
hurdles. libgcc is trying to compile unwind*.c files which I can't 
remember being there for GCC46. I deduce this files have to do with 
exception support GCC47 seems to want to make exceptions mandatory even 
though my backend doesn't really 'support' them (in the sense that our 
tests don't care about them).

unwind*.c have a lot of variable definitions to mode SI as being a word, 
However, in my case a word is actually in mode QI (16bits). Is there 
anything I can do to stop libgcc from trying to compile these files or to 
make unwind compatible with my backend besides going blindly changing SI 
mode in variable declaration to QI mode?

Cheers,
-- 
PMatos

Re: unwind and type support in GCC47

[Ian Lance Taylor]

"Paulo J. Matos" <paulo@matos-sorge.com> writes:

> I am porting my backend to GCC47 and have been jumping through some 
> hurdles. libgcc is trying to compile unwind*.c files which I can't 
> remember being there for GCC46.

They were there.  In 4.6 they were in the gcc subdirectory.  For 4.7
they moved to the libgcc directory.  This was a logical move because
they have always been part of libgcc, not part of the compiler (and
enormous thanks for Rainer Orth for working through the mechanics of
moving them.)


> I deduce this files have to do with 
> exception support GCC47 seems to want to make exceptions mandatory even 
> though my backend doesn't really 'support' them (in the sense that our 
> tests don't care about them).

The files didn't change when they moved.  It is possible that something
about how they were built changed.


> unwind*.c have a lot of variable definitions to mode SI as being a word, 
> However, in my case a word is actually in mode QI (16bits). Is there 
> anything I can do to stop libgcc from trying to compile these files

Sure, change LIB2ADDEH in your libgcc/config/CPU/t-CPU file.  E.g., see
picochip.

> or to 
> make unwind compatible with my backend besides going blindly changing SI 
> mode in variable declaration to QI mode?

There really shouldn't be anything in the exception support that uses
SImode.  That would be a bug.  And I don't see anything that uses
SImode.  What are you looking at?  What I see is things that use mode
__unwind_word__, __word__, and __pointer__.  Those types are under the
control of your backend.

Ian

Re: unwind and type support in GCC47

[Paulo J. Matos]

On 30/03/12 05:11, Ian Lance Taylor wrote:
> "Paulo J. Matos"<paulo@matos-sorge.com>  writes:
>
>> I am porting my backend to GCC47 and have been jumping through some
>> hurdles. libgcc is trying to compile unwind*.c files which I can't
>> remember being there for GCC46.
>
> They were there.  In 4.6 they were in the gcc subdirectory.  For 4.7
> they moved to the libgcc directory.  This was a logical move because
> they have always been part of libgcc, not part of the compiler (and
> enormous thanks for Rainer Orth for working through the mechanics of
> moving them.)
>

You are right, they were but they were not being compiled for my target. 
The reason they were being compiled for GCC47 is my fault and a problem 
with way I moved config files accross.

>> or to
>> make unwind compatible with my backend besides going blindly changing SI
>> mode in variable declaration to QI mode?
>
> There really shouldn't be anything in the exception support that uses
> SImode.  That would be a bug.  And I don't see anything that uses
> SImode.  What are you looking at?  What I see is things that use mode
> __unwind_word__, __word__, and __pointer__.  Those types are under the
> control of your backend.
>

I was mentioning these references to SI:
unwind-pe.h:
static const unsigned char *
read_encoded_value_with_base (unsigned char encoding, _Unwind_Ptr base,
                               const unsigned char *p, _Unwind_Ptr *val)
{
   union unaligned
     {
       void *ptr;
       unsigned u2 __attribute__ ((mode (HI)));
       unsigned u4 __attribute__ ((mode (SI)));
       unsigned u8 __attribute__ ((mode (DI)));
       signed s2 __attribute__ ((mode (HI)));
       signed s4 __attribute__ ((mode (SI)));
       signed s8 __attribute__ ((mode (DI)));
     } __attribute__((__packed__));
...


There are also some references to mode SI in unwind-dw2.c.

And there's also this:
unwind-dw2-fde.h:typedef          int  sword __attribute__ ((mode (SI)));

Why hardcode these type sizes here?	

Cheers,

-- 
PMatos

Re: unwind and type support in GCC47

[Ian Lance Taylor]

"Paulo J. Matos" <paulo@matos-sorge.com> writes:

> On 30/03/12 05:11, Ian Lance Taylor wrote:
>
>> There really shouldn't be anything in the exception support that uses
>> SImode.  That would be a bug.  And I don't see anything that uses
>> SImode.  What are you looking at?  What I see is things that use mode
>> __unwind_word__, __word__, and __pointer__.  Those types are under the
>> control of your backend.
>>
>
> I was mentioning these references to SI:
> unwind-pe.h:
> static const unsigned char *
> read_encoded_value_with_base (unsigned char encoding, _Unwind_Ptr base,
>                               const unsigned char *p, _Unwind_Ptr *val)
> {
>   union unaligned
>     {
>       void *ptr;
>       unsigned u2 __attribute__ ((mode (HI)));
>       unsigned u4 __attribute__ ((mode (SI)));
>       unsigned u8 __attribute__ ((mode (DI)));
>       signed s2 __attribute__ ((mode (HI)));
>       signed s4 __attribute__ ((mode (SI)));
>       signed s8 __attribute__ ((mode (DI)));
>     } __attribute__((__packed__));
> ...

Hmmm, you're right, I didn't notice those.  You said that on your system
QImode is 16 bits.  These modes are being used to efficiently load
16-bit, 32-bit, and 64-bit values, in order to handle DW_EH_PE_udata2
and friends.  This code is not portable in that it assumes 8 bit bytes
and 8 bit QImode.  But I don't know how to fix it.  What is the right
way to load a 16-bit or 32-bit value on your system?


> There are also some references to mode SI in unwind-dw2.c.
>
> And there's also this:
> unwind-dw2-fde.h:typedef          int  sword __attribute__ ((mode (SI)));
>
> Why hardcode these type sizes here?	

That just looks like a bug.  It should probably use __INT32_TYPE__
instead.

Ian

Re: unwind and type support in GCC47

[Paulo J. Matos]

On 03/04/12 15:04, Ian Lance Taylor wrote:
 > "Paulo J. Matos"<paulo@matos-sorge.com>  writes:
 >
 >
 > Hmmm, you're right, I didn't notice those.  You said that on your system
 > QImode is 16 bits.  These modes are being used to efficiently load
 > 16-bit, 32-bit, and 64-bit values, in order to handle DW_EH_PE_udata2
 > and friends.  This code is not portable in that it assumes 8 bit bytes
 > and 8 bit QImode.  But I don't know how to fix it.  What is the right
 > way to load a 16-bit or 32-bit value on your system?
 >

Registers are 16bits. Minimum addressable unit is 16bits. QImode is 
16bits, HImode is 32bits, SImode is 64bits.

Loading 16bits in my system is extremely efficient since it's just the 
load of a word.
ld AL, H'beef

will do it.
My guess it that changing that structure so that I use QI instead of HI, 
HI instead of SI and SI instead of DI will work.

 >
 >> There are also some references to mode SI in unwind-dw2.c.
 >>
 >> And there's also this:
 >> unwind-dw2-fde.h:typedef          int  sword __attribute__ ((mode 
(SI)));
 >>
 >> Why hardcode these type sizes here?	
 >
 > That just looks like a bug.  It should probably use __INT32_TYPE__
 > instead.
 >

That would be great because it would make it a lot more portable across 
really weird backends, like mine. :)

-- 
PMatos