Porting GDB to an architecture with a shared memory model

Porting GDB to an architecture with a shared memory model

[Max Larsson via Gdb]

Hi everyone,

I porting or better trying to report GDB to the AmigaOS 4 PPC target (elf
based).
I already succeeded in (re)porting the binutils stuff, but I'm stuck with
GDB.

I have a working nat, which can create an inferior, set breakpoints,etc..
but
because the target has a shared memory model, the inferior is not accessible
at the vma addresses as specified in the elf format. Currently I'm trying
to translate
the vma addresses used by the gdb core to the physical address where the
inferior
ist loaded.

I found in the source the method "set_gdbarch_has_shared_address_space" and
"exec_set_action_address", with which I think I could tell the gdb core
where the inferior
is loaded, so that I don't need to translate the address, but until know I
wasn't
able to use them correctly.

So can someone give me a hint how to realize that, or how gdb support such
a target,
or not?

kind regards

Max

Re: Porting GDB to an architecture with a shared memory model

[Luis Machado via Gdb]

On 7/28/24 18:33, Max Larsson via Gdb wrote:
> Hi everyone,
> 
> I porting or better trying to report GDB to the AmigaOS 4 PPC target (elf
> based).
> I already succeeded in (re)porting the binutils stuff, but I'm stuck with
> GDB.
> 
> I have a working nat, which can create an inferior, set breakpoints,etc..
> but
> because the target has a shared memory model, the inferior is not accessible
> at the vma addresses as specified in the elf format. Currently I'm trying
> to translate
> the vma addresses used by the gdb core to the physical address where the
> inferior
> ist loaded.
> 
> I found in the source the method "set_gdbarch_has_shared_address_space" and

I think the gdbarch_has_shared_address_space gets used to tell gdb to reuse the
address space rather than creating a new one, which is a step in the right direction.

> "exec_set_action_address", with which I think I could tell the gdb core

exec_set_section_address I suppose? That seems to get used in some places still,
which is good.

I think objfile_relocate is something that should be used here (maybe indirectly through
some other means), maybe alongside some information about where in memory things were
loaded for your case. But I can't see a way for you to directly influence the way is works.

> where the inferior
> is loaded, so that I don't need to translate the address, but until know I
> wasn't
> able to use them correctly.
> 
> So can someone give me a hint how to realize that, or how gdb support such
> a target,
> or not?

I can tell gdb supports/used to support uclinux, but I'm not sure about the
state of such support currently.

Maybe set_objfile_default_section_offset, which eventually calls objfile_relocate
could provide hints on how you could change gdb's view of the memory positioning.

Also, check gdb/tic6x-linux-tdep.c and how it relocates things through a solib
layer (gdb/solib-dsbt.c I think). For instance, dsbt_relocate_main_executable.

Re: Porting GDB to an architecture with a shared memory model

[Max Larsson via Gdb]

Hi Luis,

Thanks for the hints, after testing various cases the objfile_relocate
method is the one,
which can perform the magic as long the symfile_object_file is given in the
current_program_space.

Because I found svr4_relocate_main_executable, which performs a solution
with the mention exec_set_section_address
if no symfile_object_file is present but a exec_bfd().

Now under which circumstances can a exec_bfd(9 be present but
no symfile_object_file?

kind regards

Max



On Mon, Jul 29, 2024 at 9:36 AM Luis Machado <luis.machado@arm.com> wrote:

> On 7/28/24 18:33, Max Larsson via Gdb wrote:
> > Hi everyone,
> >
> > I porting or better trying to report GDB to the AmigaOS 4 PPC target (elf
> > based).
> > I already succeeded in (re)porting the binutils stuff, but I'm stuck with
> > GDB.
> >
> > I have a working nat, which can create an inferior, set breakpoints,etc..
> > but
> > because the target has a shared memory model, the inferior is not
> accessible
> > at the vma addresses as specified in the elf format. Currently I'm trying
> > to translate
> > the vma addresses used by the gdb core to the physical address where the
> > inferior
> > ist loaded.
> >
> > I found in the source the method "set_gdbarch_has_shared_address_space"
> and
>
> I think the gdbarch_has_shared_address_space gets used to tell gdb to
> reuse the
> address space rather than creating a new one, which is a step in the right
> direction.
>
> > "exec_set_action_address", with which I think I could tell the gdb core
>
> exec_set_section_address I suppose? That seems to get used in some places
> still,
> which is good.
>
> I think objfile_relocate is something that should be used here (maybe
> indirectly through
> some other means), maybe alongside some information about where in memory
> things were
> loaded for your case. But I can't see a way for you to directly influence
> the way is works.
>
> > where the inferior
> > is loaded, so that I don't need to translate the address, but until know
> I
> > wasn't
> > able to use them correctly.
> >
> > So can someone give me a hint how to realize that, or how gdb support
> such
> > a target,
> > or not?
>
> I can tell gdb supports/used to support uclinux, but I'm not sure about the
> state of such support currently.
>
> Maybe set_objfile_default_section_offset, which eventually calls
> objfile_relocate
> could provide hints on how you could change gdb's view of the memory
> positioning.
>
> Also, check gdb/tic6x-linux-tdep.c and how it relocates things through a
> solib
> layer (gdb/solib-dsbt.c I think). For instance,
> dsbt_relocate_main_executable.
>