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.
Quoted 1 line · In message <[email protected]> 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.
Quoted 1 line
the execution address. Doesn't this make it difficult to debug?
It doesn't make it easier, but not really difficult either.
Quoted 2 lines
Instead, I changed the
u-boot.ldsfile (not for KEV7A400) to properly set the load address and the execution address.
What do you mean by "properly"?
Best regards,
Wolfgang Denk
Signature · 3 lines
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!
Quoted 10 lines · Wolfgang Denk
Quoted 1 line · In message <[email protected]> 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.
Quoted 1 line
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.
Quoted 4 lines
Quoted 2 lines
Instead, I changed the
u-boot.ldsfile (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.
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 2 lines
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.
Quoted 1 line
one because it is too easy to make the linker do the heavy lifting.
But this does not work for all architectures / all boards.
Quoted 6 lines
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.
Quoted 2 lines
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.
Quoted 3 lines
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
Signature · 4 lines
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