[U-Boot-Users] Destination link address

[U-Boot-Users] Destination link address

[Marc Singer]

Wolfgang, you say that most targets link to the NV address instead of
the execution address.  Doesn't this make it difficult to debug?

Instead, I changed the u-boot.lds file (not for KEV7A400) to properly
set the load address and the execution address.

[U-Boot-Users] Destination link address

[Wolfgang Denk]

In message <20030708025405.GA3093@buici.com> you wrote:
> Wolfgang, you say that most targets link to the NV address instead of

Not most targets. All targets  shall  do  this,  to  make  the  setup
identical  to  all  architectures. I don't like special cases when we
can avoid them.

> the execution address.  Doesn't this make it difficult to debug?

It doesn't make it easier, but not really difficult either.

> Instead, I changed the u-boot.lds file (not for KEV7A400) to properly
> set the load address and the execution address.

What do you mean by "properly"?


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Star Trek Lives!

[U-Boot-Users] Destination link address

[Marc Singer]

On Tue, Jul 08, 2003 at 12:56:48PM +0200, Wolfgang Denk wrote:
> In message <20030708025405.GA3093@buici.com> you wrote:
> > Wolfgang, you say that most targets link to the NV address instead of
> 
> Not most targets. All targets  shall  do  this,  to  make  the  setup
> identical  to  all  architectures. I don't like special cases when we
> can avoid them.
> 
> > the execution address.  Doesn't this make it difficult to debug?
> 
> It doesn't make it easier, but not really difficult either.

Let me rephrase that.  It makes it impossible to use GDB since the
symbols don't point to the correct base.  I suppose that there might
be a command in GDB to move the base address.  I've never looked for
one because it is too easy to make the linker do the heavy lifting.

> > Instead, I changed the u-boot.lds file (not for KEV7A400) to properly
> > set the load address and the execution address.
> 
> What do you mean by "properly"?

When I was working on the x86 version, I wanted to be able to debug
all of the code using gdb.  This means telling the linker exactly what
is going on.  It has directives to indicate the difference between
load address and execution address for just this purpose.  So,
'proper' means that the ELF file reflects what is happen when the
program runs.

What I don't see is the utility of linking code to an address where it
definitely won't execute.  If it is moved elsewhere due to exigencies
of the target then there is nothing we can do about that.  However, if
it is likely to execute at a known address it is helpful to make that
clear in the ELF file.

Cheers.

[U-Boot-Users] Destination link address

[Wolfgang Denk]

In message <20030708140659.GA26624@buici.com> you wrote:
>
> > It doesn't make it easier, but not really difficult either.
> 
> Let me rephrase that.  It makes it impossible to use GDB since the
> symbols don't point to the correct base.  I suppose that there might
> be a command in GDB to move the base address.  I've never looked for

You can use GDB. Just use the "add-symbol-file" to  load  the  symbol
table to the relocation address.

> one because it is too easy to make the linker do the heavy lifting.

But this does not work for all architectures / all boards.

> When I was working on the x86 version, I wanted to be able to debug
> all of the code using gdb.  This means telling the linker exactly what
> is going on.  It has directives to indicate the difference between
> load address and execution address for just this purpose.  So,
> 'proper' means that the ELF file reflects what is happen when the
> program runs.

This does not help much, or does it? In  the  end  you  will  burn  a
binary image to some flash memory, right? Then this method breaks.

> What I don't see is the utility of linking code to an address where it
> definitely won't execute.  If it is moved elsewhere due to exigencies

We link the code to the flash  address  where  it  _starts_executing_
when  the  CPU  wakes  up  from  reset.  The  fact  that it might get
relocated to a different address somewhere in  RAM  is  a  completely
different story. Um, at least a different (later) chapter.

> of the target then there is nothing we can do about that.  However, if
> it is likely to execute at a known address it is helpful to make that
> clear in the ELF file.

But the ELF file cannot be installed in flash.

You may want to read the README for some explanations how  his  works
for example on PowerPC systems.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
It is necessary to have purpose.
	-- Alice #1, "I, Mudd", stardate 4513.3