> "rth" == Richard Henderson writes:
rth> Oh, of course. GDB is seeing the sequence of CFA's:
rth>X foo
rth>X-4 __mips16_call_stub_df_0
rth>X caller
rth> and it is sanity checking the stack is monotonic.
rth> Which seems like a fairly reasonable thing to do...
Re
On 02/16/2012 11:30 AM, Richard Sandiford wrote:
> Seems to be the same:
>
> #0 0x00400ae2 in foo() ()
> #1 0x77d793fc in __mips16_call_stub_df_0 () at ...
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
> (this is a gdb built from 7.4 branch FWIW).
Oh, of course. G
Richard Henderson writes:
> On 02/16/2012 10:58 AM, Richard Sandiford wrote:
>>> As a workaround for 4.7, you can try this hack:
>>>
>>> .cfi_startproc simple
>>> .cfi_def_cfa29, -1 # fake cfa one byte below sp
>>> .cfi_register 29, 29 # "save" sp in itself so w
On 02/16/2012 10:58 AM, Richard Sandiford wrote:
>> As a workaround for 4.7, you can try this hack:
>>
>> .cfi_startproc simple
>> .cfi_def_cfa29, -1 # fake cfa one byte below sp
>> .cfi_register 29, 29 # "save" sp in itself so we don't use
>> the fake cfa
>>
Richard Henderson writes:
> On 02/15/2012 11:53 AM, Richard Sandiford wrote:
>> We then trip:
>>
>> /* Don't let us unwind past the handler context. */
>> gcc_assert (!match_handler);
>>
>> in _Unwind_RaiseException_Phase2. What's the right thing to do here?
>>
>
> Ug. The Right
On 02/16/2012 07:40 AM, Andreas Krebbel wrote:
> On 02/15/2012 08:53 PM, Richard Sandiford wrote:
>> This fixes gdb backtraces from a stripped executable, but libgcc's
>> unwinder seems to get confused by having a stub in the middle of the
>> trace that (a) isn't a signal handler and (b) has no fra
On 02/15/2012 08:53 PM, Richard Sandiford wrote:
> This fixes gdb backtraces from a stripped executable, but libgcc's
> unwinder seems to get confused by having a stub in the middle of the
> trace that (a) isn't a signal handler and (b) has no frame of its own.
> The CFA at the point of the call to
On 02/15/2012 11:53 AM, Richard Sandiford wrote:
> We then trip:
>
> /* Don't let us unwind past the handler context. */
> gcc_assert (!match_handler);
>
> in _Unwind_RaiseException_Phase2. What's the right thing to do here?
>
Ug. The Right Thing is to fix the unwinder so that it
I'm showing my ignorance here, but couldn't find an example of something
similar on another RISCy target, so here goes...
My latest round of testing showed these failures for MIPS16:
FAIL: 21_strings/basic_string/numeric_conversions/char/stod.cc execution test
FAIL: 21_strings/basic_string/numeri
