[PATCH] Fix frame ID comparison problem on s390

Daniel Jacobowitz drow@false.org
Thu May 20 14:17:00 GMT 2004


On Thu, May 20, 2004 at 03:31:56PM +0200, Ulrich Weigand wrote:
> Hello,
> 
> even after the siglongjmp patch, there was still one failure reported
> with the signull test case on s390(x).
> 
> The reason turned out to be a problem with frame ID comparison.  In
> the back trace we have
>   handler
>   <sigtramp>
>   <NULL call>
>   caller
> 
> As the NULL call doesn't set up a stack frame, and because our CFA is
> determined by stack pointer at function entry, this means that the 
> NULL call frame and the sigtramp frame have the same 'stack_addr'
> component of their respective frame IDs.
> 
> Furthermore, the NULL call frame has 0 as 'code_addr' component of the
> frame ID, because the current PC is in fact 0.
> 
> Due to the way frame ID comparison works, this causes the two IDs to
> compare equal: the stack_addr is equal, and a zero code_addr is
> considered a wild card matching any code_addr.
> 
> This in turn causes the backtrace to abort since it encounters two
> frames with the same frame ID ...

I think the only reason this doesn't happen on i386 is that we appear
to use the SP at function entry rather than the SP at the call site,
and there's an implicit push of the return address.

Rather than cheat in the backend - most other backends will probably
have the same issue - I'd like to know what's actually using the code
wildcard.

-- 
Daniel Jacobowitz



More information about the Gdb-patches mailing list