This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB 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] frame_id_inner check and -fsplit-stack


> Date: Tue, 29 Dec 2009 23:07:20 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> 
> Ian Taylor just reported on the GDB IRC that the frame_id_inner
> check in get_prev_frame_1 is making debugging difficult when
> the program has been built with -fsplit-stack. This option
> <<permits discontiguous stack segments. The stack segments are
> just allocated using mmap, so there is no particular ordering>>.
> As a result, if two frames are on different stack segments,
> the ordering of the segments might be such that two valid frames
> might be failing the frame_id_inner check.
> 
> Discussing with Ian, he indicated that it should be easy to produce
> a section with magic name. This would allow us to determine that
> the program uses split-stack and that the frame_id_inner may not
> apply.
> 
> I can see the following options:
> 
>   1. do nothing (ahem);
>   2. remove the check entirely; we currently apply it I think
>      when the two frames are normal frames.  We already skip it
>      when either frame is not normal.
>   3. provide a user setting that allows the user to tell GDB
>      that the program uses split stacks;
>   4. skip the test when split stacks is detected.
> 
> I don't think we should really consider option (3) if we can indeed
> easily detect split-stack. (1) seems a bit harsh. I am Ok with either
> (2) or (4). It sounds like Ian is willing to make it easy for us to
> detect split-stack, so I'd vote for (4).  Given that nearly all the code
> we debug does not use split-stack, we can keep the frame_id_inner check
> a while longer...
> 
> Thoughts?

Ugh, another small step towards completely undebuggable code.  Guess
somebody is trying to cram too much bloated overthreaded C++ code into
an onderpowered 32-bit device ;).

I think we shouldn't add a knob if we don't need to.  So I'd say we
defenitely should try (4).  My initial idea for implementing this
would be for the unwinder to mark the frames that "split" the stack
(i.e. make the not normal), and skip the check for those frames.  I
also think the information should be encoded in the debug information
instead of magic section names that could be lost during (re)linking.


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