From: Martin Galvan <martin.galvan@tallertechnologies.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: Pedro Alves <palves@redhat.com>,
gdb-patches@sourceware.org, dje@google.com,
Eli Zaretskii <eliz@gnu.org>,
Daniel Gutson <daniel.gutson@tallertechnologies.com>
Subject: Re: [PATCH] Python API: Add gdb.is_in_prologue and gdb.is_in_epilogue.
Date: Thu, 23 Oct 2014 18:09:00 -0000 [thread overview]
Message-ID: <CAOKbPbZQEKeoqAoi9YEnj0spDOrVxKAdBSuY_NM-jgZ1D3LC=g@mail.gmail.com> (raw)
In-Reply-To: <201410231757.s9NHvX3r026780@d06av02.portsmouth.uk.ibm.com>
On Thu, Oct 23, 2014 at 2:57 PM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> 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 ...
While that may be true, it's also true that at some points we still
see the local variables having wrong values when stepping through
machine code. The aim of this patch is to expose a way of detecting
such situations for scripts that may need it. Until we have a safer
way to do it I think this should be integrated to the code base.
--
Martín Galván
Software Engineer
Taller Technologies Argentina
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: 54 351 4217888 / +54 351 4218211
next prev parent reply other threads:[~2014-10-23 18:09 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
2014-10-23 18:09 ` Martin Galvan [this message]
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='CAOKbPbZQEKeoqAoi9YEnj0spDOrVxKAdBSuY_NM-jgZ1D3LC=g@mail.gmail.com' \
--to=martin.galvan@tallertechnologies.com \
--cc=daniel.gutson@tallertechnologies.com \
--cc=dje@google.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=uweigand@de.ibm.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