> "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
