When U-Boot starts it is running from ROM space. Running from flash would
make it nearly impossible to read from flash while executing code from flash
not to speak of updating the U-Boot image in flash itself. To be able to do
just that, U-Boot relocates itself to RAM. We therefore
have two phases with different program addresses. The following sections
show how to debug U-Boot in both phases.

For debugging U-Boot after relocation we need to know the address to which
U-Boot relocates itself to. When no exotic features like PRAM are used, this
address usually is <MAXMEM> - CONFIG_SYS_MONITOR_LEN. In our example with 16MB
RAM and CONFIG_SYS_MONITOR_LEN = 192KB this yields the address 0x1000000 - 0x30000 =
0xFD0000.

In other cases, check the source code, and apply some common sense.
For example, on Power Architecture® we use "r2" to hold a pointer to the "global
data" structure ("struct global_data"); this structure contains a
field

unsigned long relocaddr; /* Start address of U-Boot in RAM */

which is the start addresses of U-Boot after relocation to
RAM. You can easily print this value in gdb like that:

(gdb) print/x ((gd_t *)$r2)->relocaddr

With this knowledge, we can instruct gdb to forget the old symbol table
and reload the symbols with our calculated offset:

board_init_r is the first C routine running in the newly relocated C friendly RAM
environment.

The simple example above relocates the symbols of only one section, .text.
Other sections of the executable image (like .data, .bss, etc.) are not relocated
and this prevents gdb from accessing static and global variables by name.
See more sophisticated examples in section
10.3. GDB Startup File and Utility Scripts.