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