(no subject)

[Max Larsson via Gdb]

Hi everyone,

I/We (The others do the testing, I do the coding) do have a problem the our
port of GDB to AmigaOS4 (PowerPC, big-endian, 32bit cpu, ELF, single/shared
address space).

My current port is based around GDB version 14, works in regards that it
compiles,runs, can start inferiors etc. Simple debug cases works already.

My problem in some cases are breakpoints. And the issue arise from the fact
that the target has a single address space for all running programs.
So when the inferior is launched, my nat tells the gdb core on which
address the exe is really running.

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.

Now the (my) nat loads the exe, figure out where the OS loaded it and
correct the addresses in the section_offets and calls objfile_relocate.
As more or less next step gdb tells the nat to place a breakpoint at the
address 0x010000054 via (xfer_partial).

And that is my problem that address isn't valid. I would have assumed that
gdb is smart to know that if the exe is relocated the defined
breakpoints needs to be adapted.

So Am I wrong, do I need to check all address passed in in xfer_partial and
do my own mapping in my nat?
Or is there some magic hidden settings I need to activate?
Or theoretically it should work, but because modern OS separates each exe
in their own virtuell address space the feature hasn't been tested
for years and thus wen bust?

Any hint/information is highly welcome.

kind regards

Max Larsson

Re: (unknown)

[Andreas Schwab via Gdb]

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?

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Breakpoints in shared address space

[Max Larsson via Gdb]

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"

KR

Max Larsson

BTW: Edit the subject which I forget in my initial email

Re: Breakpoints in shared address space

[Andrew Burgess via Gdb]

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

Re: Breakpoints in shared address space

[Max Larsson via Gdb]

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
>
>