From: Mark Kettenis <kettenis@gnu.org>
To: gdb@sources.redhat.com
Subject: [RFC] Is skip_prologue_using_sal actually usable?
Date: Sun, 07 Nov 2004 14:28:00 -0000 [thread overview]
Message-ID: <200411071355.iA7DtfTE002934@elgar.sibelius.xs4all.nl> (raw)
It defenitely has bugs; if the compiler only generates a single line
table entry for a function, it will skip the entire function. That
can easily be fixed by the attached patch, but it seems we're really
confused with what skipping the prologue should actually do. It seems
that in some instances we implement:
1. Skip instructions from the start of the function until we encounter
the first instruction that doesn't belong to the prologue.
while in other cases we implement:
2. Skip instructions from the start of the function until we have seen
all instructions belonging to the prologue.
Back in the old days, when prologues were fixed, 1 and 2 were pretty
much equivalent. However, these days, with compilers migrating many
instructions into the prologue, the difference can be huge, and making
the wrong choice can be very annoying.
Core GDB code seems to use skipping the prologue for a single purpose:
determining the first line with "real code" of a function, to place a
breakpoint at that location or to determine where it should stop when
stepping into a function. For this purpose I argue that we should
implement 1 instead of 2. Implementing 2 means that we run the risk
of skipping interesting code. If that code contains a branch, things
really break down because it means that GDB might never actually stop
in a function on which the user placed a breakpoint, or that GDB will
run until the program exits if you step into a function.
The drawback of implementation 1 is mainly that the prologue isn't
completely finished when GDB stops. This means that GDB might not
print function arguments correctly because the stack frame hasn't been
fully setup yet.
The problem we're facing here's that our testsuite has many tests that
break down if we skip to little but almost none that break down if we
skip too much. However, in real life, it's better to skip too little
than to much, as I argued above.
Things are complicated further by trying to skip the prologue by using
line number information. Some compilers generate line number info for
the first instruction of a function, others don't. In addition to
that, compilers generate buggy line number info. It seems that
everytime GCC gains a new optimization that moves more stuff into the
prologue, the line number info generated for these instructions isn't
quite right. As such, I think we should be very conservative when
skipping prologues solely using line number info, stopping at the line
containing the lowest address instead of the lowest line number as
skip_prologue_using_sal does.
Thoughts?
Mark
Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.141
diff -u -p -r1.141 symtab.c
--- symtab.c 22 Oct 2004 20:58:56 -0000 1.141
+++ symtab.c 7 Nov 2004 13:45:55 -0000
@@ -4050,6 +4050,11 @@ skip_prologue_using_sal (CORE_ADDR func_
prologue_sal = sal;
}
}
+
+ /* Avoid skipping the entire function. */
+ if (prologue_sal.end >= end_pc)
+ return 0;
+
return prologue_sal.end;
}
\f
next reply other threads:[~2004-11-07 13:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-07 14:28 Mark Kettenis [this message]
2004-11-09 2:43 ` Randolph Chung
2004-11-09 10:16 ` Daniel Jacobowitz
2004-11-09 14:35 ` Mark Kettenis
2004-11-09 14:51 ` Daniel Jacobowitz
2004-11-09 14:56 ` Andrew Cagney
2004-11-09 16:07 ` Mark Kettenis
2004-11-09 16:55 ` 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=200411071355.iA7DtfTE002934@elgar.sibelius.xs4all.nl \
--to=kettenis@gnu.org \
--cc=gdb@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