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

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.