From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: martin.galvan@tallertechnologies.com (Martin Galvan)
Cc: palves@redhat.com (Pedro Alves),
gdb-patches@sourceware.org, dje@google.com,
eliz@gnu.org (Eli Zaretskii)
Subject: Re: [PATCH] Python API: Add gdb.is_in_prologue and gdb.is_in_epilogue.
Date: Thu, 23 Oct 2014 17:57:00 -0000 [thread overview]
Message-ID: <201410231757.s9NHvX3r026780@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <CAOKbPbZJfQYmGk9PyQ2C7Y-hat-KxfvR-pC4sNHpF4_zdarRfQ@mail.gmail.com> from "Martin Galvan" at Oct 23, 2014 02:36:24 PM
Martin Galvan wrote:
> Well, the comment at the top of in_prologue says "Returns 1 if PC
> *might* be in prologue, 0 if definately (sic) *not* in prologue".
> However, looking at the function itself it relies on the compiler
> having marked the prologue as its own "line", and if it can't use that
> info it falls back to using the architecture-dependant
> gdbarch_skip_prologue. So far every time I've tested it it's worked
> fine, and if it didn't it would've probably already been reported as a
> bug of in_prologue or gdbarch_skip_prologue. I guess if you want to be
> *really* careful I could change that line in the documentation for
> something like "if the result is False, you can be almost sure GDB is
> right", or "GDB is most likely right".
The fundamental problem is that the notion of "prologue" and "epilogue"
simply no longer exists in optimized code generated by modern compilers;
and even more compiler features get implemented that make those notions
even less useful (e.g. shrink-wrapping).
As a result, we have been trying to the rid of using those notions as
much as possible; for example, when debugging optimized code with modern
DWARF information present, GDB will today no longer even use prologue
skipping at all. Instead, the debug information is good enough that
the correct location of local variables can be recovered at every
instruction in the function, making the distinction no longer needed.
The in_prologue routine is likewise only still uses under certain rather
rare circumstances; in fact it might even today be possible to simply
remove it. Once more platforms provide correct DWARF covering epilogues
as well, the gdbarch_in_function_epilogue_p calls in breakpoint.c may
likewise become unnecessary.
So if we hope at some point to get rid of those routines, then it seems
counterproductive to now export them as part of a fixed external API ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2014-10-23 17:57 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-22 14:02 Martin Galvan
2014-10-22 15:10 ` Eli Zaretskii
2014-10-22 15:14 ` Martin Galvan
2014-10-22 17:33 ` Martin Galvan
2014-10-22 17:47 ` Eli Zaretskii
2014-10-22 18:06 ` Martin Galvan
2014-10-22 18:07 ` Eli Zaretskii
2014-10-22 18:32 ` Martin Galvan
2014-10-22 18:37 ` Eli Zaretskii
2014-10-22 19:23 ` Doug Evans
2014-10-22 21:34 ` Pedro Alves
2014-10-22 21:59 ` Pedro Alves
2014-10-23 17:36 ` Martin Galvan
2014-10-23 17:57 ` Ulrich Weigand [this message]
2014-10-23 18:09 ` Martin Galvan
2014-10-23 18:14 ` Daniel Gutson
2014-10-24 2:42 ` Doug Evans
2014-10-24 14:58 ` Pedro Alves
2014-10-24 4:57 ` Doug Evans
2014-10-24 15:02 ` Pedro Alves
2014-10-24 15:34 ` Ulrich Weigand
2014-10-24 15:47 ` Doug Evans
2014-10-24 14:57 ` Pedro Alves
2014-10-24 15:13 ` Ulrich Weigand
2014-11-07 14:45 ` [push] Revert old nexti prologue check and eliminate in_prologue Pedro Alves
2014-10-24 19:49 ` [PATCH] Python API: Add gdb.is_in_prologue and gdb.is_in_epilogue Martin Galvan
2014-10-24 20:09 ` Pedro Alves
2014-10-24 21:11 ` Martin Galvan
2014-10-24 22:34 ` Pedro Alves
2014-10-27 16:40 ` Martin Galvan
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=201410231757.s9NHvX3r026780@d06av02.portsmouth.uk.ibm.com \
--to=uweigand@de.ibm.com \
--cc=dje@google.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=martin.galvan@tallertechnologies.com \
--cc=palves@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