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: [RFC 4.8] use ip+cfa to identify unwind frames, if possible


David Daney <david.daney@cavium.com> writes:
> On 02/16/2012 02:12 PM, Richard Henderson wrote:
> [...]

Thanks for the patch.

>> index 1c19f8b..59d4560 100644
>> --- a/gcc/config/mips/mips.h
>> +++ b/gcc/config/mips/mips.h
>> @@ -2920,3 +2920,15 @@ extern GTY(()) struct target_globals *mips16_globals;
>>      with arguments ARGS.  */
>>   #define PMODE_INSN(NAME, ARGS) \
>>     (Pmode == SImode ? NAME ## _si ARGS : NAME ## _di ARGS)
>> +
>> +/* For mips32 mode we have bits 0 and 1 zero free, but for mips16 mode,
>> +   bit 0 indicates mips16 mode, and bit 1 is thence meaningful.  Thus
>> +   the only "free" bits would be at the top of the address space.
>> +   Can we trust that we'll never try to unwind in kernel mode?  */
>
> That's too bad.  I guess if we ever want to unwind in kernel mode, we 
> can say no mips16 and switch it to a low-order bit for that application. 
>   Or write our own unwinder.

I suppose the problem is that baremetal often runs in kernel mode.
(Normal mips*-elf gdbsim testing works that way.)

But I think we'd be fine if we restrict the IP matching to non-MIPS16 mode.
GCC doesn't have any other special RA save registers, and now's a good time
to say that such a thing won't be allowed in MIPS16 or microMIPS code
(or in anything, probably).

So maybe we could set private_1 to (IP | 2) when (IP & 3) == 0,
and leave it at 0 otherwise.  It's then a forced unwind unless
(IP & 3) == 2.  Not as elegant as the single bit though.

Richard


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