public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Paul Smith <psmith@gnu.org>
To: Simon Marchi <simark@simark.ca>, gdb@sourceware.org
Subject: Re: GDB 13.2: breakpoint at wrong line after unrelated change
Date: Fri, 15 Mar 2024 17:11:48 -0400	[thread overview]
Message-ID: <3b4f943d23543da2ba96dad8c81fa8c495fffd08.camel@gnu.org> (raw)
In-Reply-To: <06c7a0d1-6ba7-440a-a21a-616ed05cb5b0@simark.ca>

On Mon, 2024-03-11 at 15:50 -0400, Simon Marchi wrote:
> Ok, so clearly GDB failed to analyze the prologue.  Which is weird
> because the two functions are identical (modulo the addresses).  To
> get to the bottom of this, you (or someone else) would need to debug
> GDB itself.  If you want to do this, I would start at function
> skip_prologue_using_sal, in symtab.c.  Off hand, I don't think we
> have a debug switch to enable logging for prologue skipping.  It
> would be useful to have some here, as we would be able to compare the
> logging shown in both cases.

FYI I have finally gotten back to looking at this.  I've only been at
it for a short time but just for information:

I was able to build GDB 14.2 (latest release) from source and I still
see the issue there.  So I started debugging.

I can tell you that in the "good" binary case I can see that
amd64_tdep.c:amd64_skip_prologue() is invoked which invokes
symtab.c:skip_prologue_using_sal() as you suggested.  In fact, these
methods are called numerous times.

In the "bad" binary case, neither of those methods is called, ever.  I
put a gdb_printf() in both functions and in the "good" binary I see
probably 20 invocations between starting, setting the breakpoint,
running, and exiting: in the "bad" binary zero invocations.  I do see
that we definitely invoke set_gdbarch_skip_prologue() with the amd64
function pointer in both cases, so it's not that.

I'm looking to see where *_skip_prologue() is called from to figure out
where the code paths diverge, just thought I'd send a note to let folks
know that I've not dropped this investigation.

  parent reply	other threads:[~2024-03-15 21:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-11 18:28 Paul Smith
2024-03-11 19:14 ` Simon Marchi
2024-03-11 19:38   ` Paul Smith
2024-03-11 19:50     ` Simon Marchi
2024-03-11 20:17       ` Paul Smith
2024-03-15 21:11       ` Paul Smith [this message]
2024-03-15 22:19         ` Paul Smith
2024-03-16 16:33           ` Simon Marchi
2024-03-16 19:57             ` Paul Smith

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=3b4f943d23543da2ba96dad8c81fa8c495fffd08.camel@gnu.org \
    --to=psmith@gnu.org \
    --cc=gdb@sourceware.org \
    --cc=simark@simark.ca \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).