Dear Scott,
In message 1354054951.2317.14@tyr you wrote:
vary after code changed. In the early debug phase it would be
easier to handle
if the relocation address does not change per build.
No, it is not.
Maybe not for you, but for some of us it definitely would make things easier. I usually end up randomly peeking at some likely destinations until I find the expected content.
We have an entry with the relocation address in the global data structure. All you need to do is read that. You can even do this using a macro definition in GDB. There is no magic involved.
Any debugger out there today allows you to automatemost such operations by scripts or functions or macros you can define to help you doing that.
Just because you've managed to compensate for it doesn't mean it isn't annoying.
You fail to understand, or see only your specific, limited set of use cases.
How am I going to script gdb to figure out the relocation address when I'm just running it on the image to get symbols, not actually connecting to the target?
You cannot, and you need not.
If you are just running GDB on the image, without actually running it on the target, there is no need to consider the relocation at all. Just use the symbols of the ELF file as is.
But _if_ you are running on the target, then in general the relocation address is NOT known in advance, as it is computed dynamically, and even on the same system it may change from one run to the next, for example depending on settings of environment variables (like pram), etc.
Is such a script published anywhere?
You are long enough in this business that I simply don't believe you if you claim you don't know how to read and print gd->relocaddr in GDB... Did you ever have a look at the documentation [1] ?
If the symbols in the ELF file match where U-Boot is actually located, that avoids the need to manually apply the relocation offset every time you want to look at something.
Typically, you run a debugger because soimething is not working as expected. In such a situation you want to debug the system that shows the problem, not something completely different. [If you have a generic problem that does not depend on specific settings, then just debug it in the sandbox.] In my experience there are more cases where a modified system (like one without relocation) just adds to the problems and is actually counter-productive.
Where would you get the symbol table to load that matches U-Boot post-relocation?
Well, if you really don't know all this after all the years, then maybe you might find it instructive to read the documentation, especially section "10.1.2. Debugging of U-Boot After Relocation" [1] ?
[1] http://www.denx.de/wiki/view/DULG/DebuggingUBoot#Section_10.1.2.
Best regards,
Wolfgang Denk