Re: Breakpoints in shared address space

[Andrew Burgess via Gdb <gdb@sourceware.org>]

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