[U-Boot-Users] code relocation and symbolic debugging

vb vb at vsbe.com
Tue Mar 20 02:05:10 CET 2007


Gentlemen,

forgive me if this has been discussed before - I tried searching the
archives and could not find anything.

I don't understand the reason for the program relocation from eprom to
dram the way it is done now (with position independent data and code,
with runtime address fixes, etc.). I mean, this of course is quite an
achievement to have this working on so many platforms, but it is such
a pain, especially when trying symbolic debugging. I of course know
about the gdb add-symbol-file command, but I couldn't figure out how
to make it relocate symbols along with the text segment. As a result,
I can set breakpoints and examine automatic variables, but can't see
static/global variables using the gdb. How do others handle this
situation - any hits will be highly appreciated.

Now, I don't want to sound too much off the mark, but why is this
trick even needed?  For at least 10 years now gnu tools provide the
ability to generate bin images of the executable files and to
concatenate otherwise noncontiguous segments in one file.

Utilizing this feature would allow to benefit from all the u-boot
early startup elegant smarts (running with data in the cache, testing
the entire dram, stc)., then the first stage code would just move the
main chunk to the predefined location and pass control to it. This way
no need to worry about adjusting tabled addresses, about data not
fitting into the room allotted, about gdb not alllowing to see
variables - this approach is pretty much worry free at least on mips
and ppc architectures where I extensively deployed it before joining
the u-boot club.

Of course with such a heavy legacy like u-boot has it is difficult to
switch on a whim, but would this be even considered? And why has not
it been done like that in the first place?

Cheers,
/vb




More information about the U-Boot mailing list