[U-Boot-Users] Destination link address
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.
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
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.
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
participants (2)
-
Marc Singer -
Wolfgang Denk