Re: Relocation question

Re: Relocation question

[Ton van Overbeek]

Andreas Schwab wrote:

>Stefan Burström <f94sbu@efd.lth.se> writes:
>
>> Can someone explain to me how gdb is supposed to handle relocated
>> executables? I am porting gdb to AmigaOS4 which relocates its
>> executables
>> when they are loaded. However, when I run an application through gdb,
>> gdb uses the bfd functions to build its map over the file. However, the
>> bfd library always relocates everything relative to 0 (since it
>> obviously doesn't know anything else to relocate it to)
>
> That reminds me of an old port of gdb 3.6 for the AtariST (which has the
> same problem).  It used CREATE_INFERIOR_HOOK (now called
> TARGET_CREATE_INFERIOR_HOOK) to query the load address of the just
> started
> process and then patched the gdb symtabs and breakpoint addresses by the
> load offset.  But I don't think that would still work nowadays.

Have a look at how we solved this in prc-tools for PalmOS:
http://prc-tools.sourceforge.net. Go to the cvs and look at the patch for
gdb. It is for gdb 5.3, but the mechanism still works for 6.x.
PalmOS can also have multiple code sections whose start addresses are not
known untill runtime. A patch supporting that is on
http://www.v-overbeek.nl/msectgdb.

Basically when execution starts (either on a real PalmOS device or on an
emulator) the start addresses of the .text and .data and other code
sections are reported to gdb, which then relocates the symbol tables.
(PalmOS is also m68k).

Hope this helps.

Ton van Overbeek
(for Andreas: my first Linux experience was with Linux-68k on Atari-TT)
(for Stefan: gjorde mitt examensarbete på LTH, Reglerteknik)

Missing "angeldll.h" in gdb/rdi-shareestion

[Dave Murphy]

Hi

While trying to build gdb-6.3 for `arm-elf` target and Mingw32 host, I get an error about a missing "angeldll.h" header. I asked about this on the Insight list some time ago but was redirected here. Where can this file be found?


thanks,
Dave

Re: Missing "angeldll.h" in gdb/rdi-shareestion

[Daniel Jacobowitz]

On Mon, Aug 15, 2005 at 05:00:46AM +0100, Dave Murphy wrote:
> Hi
> 
> While trying to build gdb-6.3 for `arm-elf` target and Mingw32 host, I get 
> an error about a missing "angeldll.h" header. I asked about this on the 
> Insight list some time ago but was redirected here. Where can this file be 
> found?

The rdi-share directory can't be built on Windows.

Also, gdb 6.3 doesn't support mingw32 host; so good luck... the best I
can offer right now is CodeSourcery's 2005-Q1 release or the
corresponding branch in the CVS repository.  You can find the packages
on the CodeSourcery website, and Mark's been working on getting this
support merged into the FSF tree, slowly.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Relocation question

[Stefan Burström]

Hello!
Can someone explain to me how gdb is supposed to handle relocated
executables? I am porting gdb to AmigaOS4 which relocates its executables
when they are loaded. However, when I run an application through gdb, gdb
uses the bfd functions to build its map over the file. However, the bfd
library always relocates everything relative to 0 (since it obviously
doesn't know anything else to relocate it to)

So, in order for gdb to build the symbol tables etc. it needs to use the
relocated addresses instead of the ones retreived directly from the file.
What is the prefered way of doing this? I tried to set up the section
offsets (real address - address from the bfd code) in the section offsets
field, but I am not quite sure exactly when I can set up this table. I tried
to set it up in the default_symfile_offsets function and that results in the
small symbol table to be correct. However, the addr and endaddr ptrs in the
objfile/osections are already set up at this point and will then contain
addresses near 0 instead. Which means that every search for an address vill
fail since it wont fall between addr and endaddr of the sections loaded from
the bfd file.

Is this possible to solive in a nice way?

regards,
Stefan Burström

Re: Relocation question

[Simon Richter]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

Hi,

Stefan Burström wrote:

> Can someone explain to me how gdb is supposed to handle relocated
> executables? I am porting gdb to AmigaOS4 which relocates its executables
> when they are loaded.

w00t! How far are you concerning bfd support for 0x3f3 binaries? I have
just started work on that as I need that to hack a new bootloader for
APUS Linux in order to survive the cleanup going on in the kernel.

> However, when I run an application through gdb, gdb
> uses the bfd functions to build its map over the file. However, the bfd
> library always relocates everything relative to 0 (since it obviously
> doesn't know anything else to relocate it to)

AFAIK gdb knows of an offset to apply to everything that needs to be set
around loading time, but I don't remember offhand how to do that. I need
such a beast myself, so I'm going to invest some time into that in the
next days (my problem at hand is that bFLT executables also get
relocated, and that it is pretty normal to have a PIC register for the
data section to allow sharing code between processes).

   Simon


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]

Re: Relocation question

[Andreas Schwab]

Stefan Burström <f94sbu@efd.lth.se> writes:

> Can someone explain to me how gdb is supposed to handle relocated
> executables? I am porting gdb to AmigaOS4 which relocates its executables
> when they are loaded. However, when I run an application through gdb, gdb
> uses the bfd functions to build its map over the file. However, the bfd
> library always relocates everything relative to 0 (since it obviously
> doesn't know anything else to relocate it to)

That reminds me of an old port of gdb 3.6 for the AtariST (which has the
same problem).  It used CREATE_INFERIOR_HOOK (now called
TARGET_CREATE_INFERIOR_HOOK) to query the load address of the just started
process and then patched the gdb symtabs and breakpoint addresses by the
load offset.  But I don't think that would still work nowadays.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."