[U-Boot] [PATCH 0/2] [RFC] DEBUG: relocate to fixed address

Wolfgang Denk wd at denx.de
Wed Nov 28 07:45:57 CET 2012


Dear Scott,

In message <1354054951.2317.14 at 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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Things are not as simple as they seem at first.        - Edward Thorp


More information about the U-Boot mailing list