Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew STUBBS <andrew.stubbs@st.com>
To: Andrew Stubbs <andrew.stubbs@st.com>
Cc: Daniel Jacobowitz <drow@false.org>, gdb-patches@sources.redhat.com
Subject: Re: [SH][PATCH] Disable ABI frame sniffer
Date: Thu, 24 Nov 2005 22:48:00 -0000	[thread overview]
Message-ID: <4385F7A0.5070907@st.com> (raw)
In-Reply-To: <4384B6B5.90207@st.com>

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

Andrew Stubbs wrote:
> I could modify the sh sniffer such that it actually does something. 
> However, this would require modifying frame_unwind_find_by_frame() and 
> family such that it can accept a NULL answer from every sniffer.

This won't work. The whole unwinding mechanism is lazy and does not 
happen until print_frame_info() has already committed to printing 
something, it just doesn't know what yet.

The reason for this is that get_prev_frame() and get_prev_frame_1() have 
already effectively promised that there will be another frame, but 
haven't actually ventured to find out what it is - that is done lazily 
as required.

It isn't possible to have the sniffer say 'I know this is the last frame 
on the stack' because, unless the compiler says so, all it really could 
tell is that this is the last frame as it knows it. It might work if the 
code asked all the sniffers and returned 'end of stack' if all of them 
fail to recognise a frame.

But, all is not lost ....

The attached patch to get_prev_frame_1() *does* fix the problem. With 
this I get exactly what I want.

I have no doubt that it is somehow horribly flawed and totally 
unacceptable, but hopefully something will emerge from all this.

BTW, the file has a comment that says 'Allocate the new frame but do not 
wire it in to the frame chain', but then it appears to go ahead and wire 
up the frame chain. Is this a mistake or am I just misunderstanding it?

Thanks

Andrew Stubbs

[-- Attachment #2: unwinder.patch --]
[-- Type: text/plain, Size: 977 bytes --]

2005-11-24  Andrew Stubbs  <andrew.stubbs@st.com>

	* frame.c (get_prev_frame_1): Check the PC is within the program
	before allowing the frame to be created.

Index: src/gdb/frame.c
===================================================================
--- src.orig/gdb/frame.c	2005-11-24 16:45:22.000000000 +0000
+++ src/gdb/frame.c	2005-11-24 17:24:09.000000000 +0000
@@ -1123,6 +1123,16 @@ get_prev_frame_1 (struct frame_info *thi
   this_frame->prev = prev_frame;
   prev_frame->next = this_frame;
 
+  /* Check that the new frame would refer to a location within the
+     program.  This has to be done after it is linked in or the
+     function calls will not work.  If the location is junk then
+     we have probably dropped off the bottom of the stack.  */
+  if (!find_pc_section (frame_unwind_address_in_block (this_frame)))
+    {
+      this_frame->prev = NULL;
+      return NULL;
+    }
+
   if (frame_debug)
     {
       fprintf_unfiltered (gdb_stdlog, "-> ");

  reply	other threads:[~2005-11-24 17:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-09 18:08 Andrew STUBBS
2005-11-10  0:17 ` Andreas Schwab
2005-11-10  3:30   ` Daniel Jacobowitz
2005-11-10 12:27     ` Andrew STUBBS
2005-11-10 14:24       ` Daniel Jacobowitz
2005-11-10  4:27 ` Daniel Jacobowitz
2005-11-10 13:36   ` Andrew STUBBS
2005-11-10 14:34     ` Daniel Jacobowitz
2005-11-10 23:09       ` Andrew STUBBS
2005-11-10 23:13         ` Andrew STUBBS
2005-11-11  0:10         ` Mark Kettenis
2005-11-11 10:31           ` Daniel Jacobowitz
2005-11-11 18:21           ` Andrew STUBBS
2005-11-11 10:35         ` Daniel Jacobowitz
2005-11-11 20:09           ` Andrew STUBBS
2005-11-13 18:57             ` Daniel Jacobowitz
2005-11-13 23:58               ` Jim Blandy
2005-11-23 19:52               ` Andrew STUBBS
2005-11-24 22:48                 ` Andrew STUBBS [this message]
2005-11-24 23:42                   ` Mark Kettenis
2005-11-10 11:11 ` Eli Zaretskii

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=4385F7A0.5070907@st.com \
    --to=andrew.stubbs@st.com \
    --cc=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    /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