Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Max Larsson via Gdb <gdb@sourceware.org>
To: Andrew Burgess <aburgess@redhat.com>
Cc: Andreas Schwab <schwab@suse.de>,
	Max Larsson via Gdb <gdb@sourceware.org>
Subject: Re: Breakpoints in shared address space
Date: Fri, 16 May 2025 13:17:27 +0200	[thread overview]
Message-ID: <CAGKMySWR1ck6yefZdUird3eVhiT2JiOH6tbuuX7tQ_qTFB1zDA@mail.gmail.com> (raw)
In-Reply-To: <875xi0onpo.fsf@redhat.com>

Hi Andrew,

thanks for the explanation. That help a lot. And even for the patch.
I think I will in cooperate that in our port.

KR

Max Larsson


On Fri, 16 May 2025 at 12:26, Andrew Burgess <aburgess@redhat.com> wrote:

> Max Larsson via Gdb <gdb@sourceware.org> writes:
>
> > On Thu, 15 May 2025 at 13:46, Andreas Schwab <schwab@suse.de> wrote:
> >
> >> On Mai 15 2025, Max Larsson via Gdb wrote:
> >>
> >> > So if gdb file command is use to read an exe, gdb uses the address for
> >> the
> >> > exe as defined in the elf file. So if i disas the _start function
> >> > it show me all the assembler code starting with an address
> 0x010000054.
> >> So
> >> > long everything is fine. Now I tell gdb to set an break point
> >> > on that address and run the exe.
> >>
> >> How do you set the breakpoint exactly?
> >>
> >>
> > Like this "b *0x010000054"
>
> GDB doesn't adjust breakpoint placed by address when an inferior is
> relocated during startup.
>
> The same problems you are encountering can (and often is) hit on Linux
> system if the executable is compiled as PIE (position independent
> executable).
>
> I did, long ago, propose a patch to GDB that would specifically warn
> about this issue:
>
>
> https://inbox.sourceware.org/gdb-patches/20200202011022.11357-1-andrew.burgess@embecosm.com/
>
> But it never got merged.
>
> If you place the breakpoint based on function name, or file/line, then
> GDB will update the breakpoints location.
>
> Alternatively, you could start the inferior, but halt before the first
> instruction using `starti`, then disassemble, at which point the
> addresses should be correct, you can then place a breakpoint by address.
>
> Your next question is likely to be: why don't address breakpoints get
> updated?  The answer is that GDB doesn't want to make assumptions about
> what the user intends.  What if they _really_ do want a b/p at that
> address?  Given there are easy solutions (`starti`) that allow the user
> to place on the correct address, right now, address breakpoints just
> don't move.
>
> Thanks,
> Andrew
>
> >
> > KR
> >
> > Max Larsson
> >
> > BTW: Edit the subject which I forget in my initial email
>
>

      reply	other threads:[~2025-05-16 11:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-15 10:53 Max Larsson via Gdb
2025-05-15 11:46 ` (unknown) Andreas Schwab via Gdb
2025-05-15 16:05   ` Breakpoints in shared address space Max Larsson via Gdb
2025-05-16 10:26     ` Andrew Burgess via Gdb
2025-05-16 11:17       ` Max Larsson via Gdb [this message]

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=CAGKMySWR1ck6yefZdUird3eVhiT2JiOH6tbuuX7tQ_qTFB1zDA@mail.gmail.com \
    --to=gdb@sourceware.org \
    --cc=aburgess@redhat.com \
    --cc=max.larsson@gmx.de \
    --cc=schwab@suse.de \
    /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