Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: brobecker@adacore.com
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] frame_id_inner check and -fsplit-stack
Date: Tue, 29 Dec 2009 19:49:00 -0000	[thread overview]
Message-ID: <200912291948.nBTJmbCx011266@glazunov.sibelius.xs4all.nl> (raw)
In-Reply-To: <20091229190720.GE24363@adacore.com> (message from Joel Brobecker 	on Tue, 29 Dec 2009 23:07:20 +0400)

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


  reply	other threads:[~2009-12-29 19:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-29 19:07 Joel Brobecker
2009-12-29 19:49 ` Mark Kettenis [this message]
2009-12-30  8:06   ` Ian Lance Taylor
2009-12-30  8:58     ` Joel Brobecker
2009-12-30 13:45     ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200912291948.nBTJmbCx011266@glazunov.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox