[U-Boot-Users] Using the abatron to debug an image in flash

[U-Boot-Users] Using the abatron to debug an image in flash

[Mark Doherty]

Hello Detlev, Wolfgang,

Thanks for your replies, you are completely correct, I should have realised!
I had some problems compiling with -O0, however building with -O1 was just
as good. 

Now I have another problem, one which I hope you may have come across
before, my debugger is failing to keep track of the updated addresses of
static variables after relocation, which makes displaying variables kinda
hard :)

Any ideas?

Mark.

[U-Boot-Users] Using the abatron to debug an image in flash

[Wolfgang Denk]

In message <9901EE1E8F8BD3119109009027A1B5F596AE42@DIGINET2> you wrote:
> 
> Now I have another problem, one which I hope you may have come across
> before, my debugger is failing to keep track of the updated addresses of
> static variables after relocation, which makes displaying variables kinda
> hard :)

Accessing normal static variables should be  no  problem.  It's  just
initialized  data  pointers  which  need  manual relocation. I try to
avoid this data type whenever possible, or we need to relocate it. If
you find unrelocated initialized pointers please let me know.

But accessing the variables itself should work just fine  -  if  they
are pointers, they will just contain unrelocated addresses.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
I have never bought, sold, nor stolen a piece of software in my life,
and would rather quit the industry than become a thrall of $Bill,  or
even touch his slimy idiocy.
         -- Tom Christiansen in <6jhtqk$qls$1@csnews.cs.colorado.edu>

[U-Boot-Users] Using the abatron to debug an image in flash

[Detlev Zundel]

Hi Mark,

> Now I have another problem, one which I hope you may have come across
> before, my debugger is failing to keep track of the updated addresses of
> static variables after relocation, which makes displaying variables kinda
> hard :)

Yes, this is a somewhat recurring question ;)  Take a look here[1] and
see if the information helps.

Cheers
  Detlev


[1] http://www.denx.de/twiki/bin/view/DULG/WrongDebugSymbolsAfterRelocation

-- 
There are three kinds of people in the world; those who can count and
those who can't.

[U-Boot-Users] Using the abatron to debug an image in flash

[Mark Doherty]

Wolfgang, 

I've rebuilt u-boot using ELDK 2.0 and found that the problem doesn't exist,
I suspect that the combination of the MV toolchain and ELDK toolchain is a
bad idea, lession well and truely learned.

Thanks for your assistance.

Mark.

[U-Boot-Users] Using the abatron to debug an image in flash

[Mark Doherty]

Hello Wolfgang, 
> > 
> > $ ppc-linux-gdb
> 
> Is this really how you called GDB?
It is indeed.
> 
> > GNU gdb 5.1.1
> 
> Where did you get this GDB from?
> 
This version of gdb is actually the version you pointed me to a few weeks
ago when I asked about debugging start.S, it does the same with  the MVL
toolchain as well so I suspect that maybe I've broken something. 

<snip>
This is probably a known problem. If you like, you can  try  out  our
latest  patches;  you  can  find  a  test version of our cross GDB at
ftp://ftp.denx.de/pub/tmp/ppc-linux-gdb - don't  forget  to  set  the
CROSS_COMPILE  environment  variable  as  needed (= ppc_82xx- in your
case) as with all our ELDK tools.
<snip>

As you illustrated, it should work, I think I'll take a look at what happens
on our ep8260s. 

thanks

Mark.

[U-Boot-Users] Using the abatron to debug an image in flash

[Mark Doherty]

Dear Wolfgang, 

> Accessing normal static variables should be  no  problem.  It's  just
> initialized  data  pointers  which  need  manual relocation. I try to
> avoid this data type whenever possible, or we need to relocate it. If
> you find unrelocated initialized pointers please let me know.
> 
> But accessing the variables itself should work just fine  -  if  they
> are pointers, they will just contain unrelocated addresses.
> 

I have loaded the symbol file as mentioned previously, however to my 
unexperienced eye it appears that some of the symbols for the static 
variables have not been loaded where I would have expected ...

$ ppc-linux-gdb
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux".
(gdb) bdi
0xff000100 in ?? ()
(gdb) ram
add symbol table from file "u-boot" at
        .text_addr = 0x7fc0000
(gdb) info address rtx
Symbol "rtx" is static storage at address 0xff0312d8.
(gdb)

In the unlikely case you are not aware rtx is defined in 
cpu/mpc8260/ether_fcc.c as ...

<snip>
/*
 * FCC Ethernet Tx and Rx buffer descriptors.
 * Provide for Double Buffering
 * Note: PKTBUFSRX is defined in net.h
 */

typedef volatile struct rtxbd {
    cbd_t rxbd[PKTBUFSRX];
    cbd_t txbd[TX_BUF_CNT];
} RTXBD;

/*  Good news: the FCC supports external BDs! */
#ifdef __GNUC__
static RTXBD rtx __attribute__ ((aligned(8)));
#else
#error "rtx must be 64-bit aligned"
#endif
<snip>

Is this what you would normally expect? When I scan the assembler the code 
uses the correct address, it appears that the gdb however is a bit lost.

Best wishes,

Mark.

[U-Boot-Users] Using the abatron to debug an image in flash

[Wolfgang Denk]

Dear Mark,

in message <9901EE1E8F8BD3119109009027A1B5F596AE43@DIGINET2> you wrote:
> 
> $ ppc-linux-gdb

Is this really how you called GDB?

> GNU gdb 5.1.1

Where did you get this GDB from?

> This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux".
> (gdb) bdi
> 0xff000100 in ?? ()
> (gdb) ram
> add symbol table from file "u-boot" at
>         .text_addr = 0x7fc0000
> (gdb) info address rtx
> Symbol "rtx" is static storage at address 0xff0312d8.
> (gdb)
> 
> In the unlikely case you are not aware rtx is defined in 
> cpu/mpc8260/ether_fcc.c as ...

The same works fine here:

	-> ppc_8xx-gdb
	GNU gdb 5.1.1
	Copyright 2002 Free Software Foundation, Inc.
	GDB is free software, covered by the GNU General Public License, and you are
	welcome to change it and/or distribute copies of it under certain conditions.
	Type "show copying" to see the conditions.
	There is absolutely no warranty for GDB.  Type "show warranty" for details.
	This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux".
	(gdb) add-symbol-file boot 0x7fc0000
	add symbol table from file "boot" at
		.text_addr = 0x7fc0000
	(y or n) y
	boot: No such file or directory.
	(gdb) add-symbol-file u-boot 0x7fc0000
	add symbol table from file "u-boot" at
		.text_addr = 0x7fc0000
	(y or n) y
	Reading symbols from u-boot...done.
	(gdb) p &_start
	$1 = (<text variable, no debug info> *) 0x7fc0100 <_start>
	(gdb) p &rtx
	$2 = (struct rtxbd *) 0x7fe20e0
	(gdb) info address rtx
	Symbol "rtx" is static storage at address 0x7fe20e0.

And just to verify without relocation:

	(gdb) symbol-file 
	Discard symbol table from `current image(s)'? (y or n) y
	No symbol file now.
	(gdb) symbol-file u-boot
	Reading symbols from u-boot...done.
	(gdb) info address rtx
	Symbol "rtx" is static storage at address 0x400220e0.
	(gdb) 




Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The C-shell doesn't parse. It adhoculates.
    - Casper.Dik at Holland.Sun.COM in <3ol96k$b2j@engnews2.Eng.Sun.COM>

[U-Boot-Users] Using the abatron to debug an image in flash

[Mark Doherty]

Hi, 

Apologies for asking what I suspect is a very simple problem, I am
attempting 
to debug u-boot after relocation and have followed the simple instructions 
previously posted on this mailing-list, however I am having difficulty in 
getting the abatron to do as it is told!

First up is the target section of the bdi2000 config file :

[TARGET]
CPUTYPE	8260
BDIMODE	AGENT
STARTUP	RESET
JTAGCLOCK	0
BOOTADDR 	0x00000100
;WORKSPACE	0x00000000
BREAKMODE	HARD
STEPMODE 	HWBP
;VECTOR	CATCH
;DCACHE	NOFLUSH
;MMU		XLAT 0xC0000000
;PTBASE	0x000000F0

I'd like to be able to step through the eth_init routine and I am invoking
it 
through a tftpboot command on the console. A trace from gdb illustrates my 
problem, (note that I have some shortcuts programmed into my .gdbinit
routine 
to set the $pc and to load the symbol file). When the program has loaded
into 
RAM I stop the debugger (hence the SIGSTOP) to insert my breakpoint, for
some 
reason I have problems if I attempt to insert the breakpoint before the code

is in RAM (?).

$ ppc-linux-gdb
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux".
(gdb) bdi
0x00000100 in ?? ()
(gdb) resethi
(gdb) ram
add symbol table from file "u-boot" at
        .text_addr = 0x7fc0000
(gdb) c
Continuing.

Program received signal SIGSTOP, Stopped (signal).
0x07fdbb18 in serial_getc () at serial_scc.c:242
242             while (rbdf->cbd_sc & BD_SC_EMPTY)
(gdb) b eth_init
Breakpoint 1 at 0x7fdc278: file ether_fcc.c, line 201.
(gdb) c
Continuing.

Breakpoint 1, eth_init (bis=0x7fa0220) at ether_fcc.c:201
201         volatile cpm8260_t *cp = &(immr->im_cpm);
(gdb) step
227         rxIdx = 0;
(gdb) step
198     {
(gdb) step
212         immr->im_cpmux.cmx_uar = 0;
(gdb) step
228         txIdx = 0;
(gdb) step
212         immr->im_cpmux.cmx_uar = 0;
(gdb) step
221         immr->im_fcc[CONFIG_ETHER_INDEX-1].fcc_fpsmr = CFG_FCC_PSMR | 
FCC_PSMR_ENCRC;
(gdb) step
213         immr->im_cpmux.cmx_fcr = (immr->im_cpmux.cmx_fcr & 
~CFG_CMXFCR_MASK) |
(gdb) step
221         immr->im_fcc[CONFIG_ETHER_INDEX-1].fcc_fpsmr = CFG_FCC_PSMR | 
FCC_PSMR_ENCRC;
(gdb) step
227         rxIdx = 0;
(gdb) step
201         volatile cpm8260_t *cp = &(immr->im_cpm);
(gdb) step
213         immr->im_cpmux.cmx_fcr = (immr->im_cpmux.cmx_fcr & 
~CFG_CMXFCR_MASK) |
(gdb) step
228         txIdx = 0;
(gdb) step
213         immr->im_cpmux.cmx_fcr = (immr->im_cpmux.cmx_fcr & 
~CFG_CMXFCR_MASK) |
(gdb)

As you can see the code appears to jump around aimlessly, though the program

still appears to run ok. Just to finish off I am able to configure the ram 
such that I can debug the application in ram up to the point where
relocation 
occurs so I am fairly confident in my SDRAM setup.

Any thoughts or comments welcome, 

thanks

Mark.

[U-Boot-Users] Using the abatron to debug an image in flash

[Detlev Zundel]

Hi Mark,

[...]

> As you can see the code appears to jump around aimlessly, though the
> program still appears to run ok. Just to finish off I am able to
> configure the ram such that I can debug the application in ram up to
> the point where relocation occurs so I am fairly confident in my
> SDRAM setup.

If the "random jumping" is your only problem, then you don't really
have a problem.  The behaviour is due to the fact the gcc has
reordered the assembler instructions to better fit the PowerPC
architecture which means that the assembler instruction sequence
_does not_ correspond 1:1 to the source lines.

If this is the problem in your case, you can try disabling all code
optimizations (-O0) for your debugging sessions.  If I am not
mistaken, this should enforce a 1:1 correspondence from source to
assembler instructions.

Cheers
  Detlev

-- 
PUBLIC NOTICE AS REQUIRED BY LAW:    Any Use of  This Product,  in Any Manner
Whatsoever, Will Increase the Amount of Disorder in the Universe. Although No
Liability Is  Implied Herein,  the Consumer Is Warned  That This Process Will
Ultimately Lead to the Heat Death of the Universe.

[U-Boot-Users] Using the abatron to debug an image in flash

[Wolfgang Denk]

Dear Mark,

in message <9901EE1E8F8BD3119109009027A1B5F596AE40@DIGINET2> you wrote:
> 
> (gdb) step
> 221         immr->im_fcc[CONFIG_ETHER_INDEX-1].fcc_fpsmr = CFG_FCC_PSMR | 
> FCC_PSMR_ENCRC;
> (gdb) step
> 213         immr->im_cpmux.cmx_fcr = (immr->im_cpmux.cmx_fcr & 
> ~CFG_CMXFCR_MASK) |
> (gdb) step
> 221         immr->im_fcc[CONFIG_ETHER_INDEX-1].fcc_fpsmr = CFG_FCC_PSMR | 
> FCC_PSMR_ENCRC;
> (gdb) step
> 227         rxIdx = 0;
> (gdb) step
> 201         volatile cpm8260_t *cp = &(immr->im_cpm);
> (gdb) step
> 213         immr->im_cpmux.cmx_fcr = (immr->im_cpmux.cmx_fcr & 
> ~CFG_CMXFCR_MASK) |
> (gdb) step
> 228         txIdx = 0;
> (gdb) step
> 213         immr->im_cpmux.cmx_fcr = (immr->im_cpmux.cmx_fcr & 
> ~CFG_CMXFCR_MASK) |
> (gdb)
> 
> As you can see the code appears to jump around aimlessly, though the program
> still appears to run ok. Just to finish off I am able to configure the ram 

Seems to be working perfectly.

Please remember that you are debugging on a C  level,  and  a  single
line  of  C code may result in several / many assembler instructions,
and the optimizer may reorder your statements as it  seems  "optimal"
to him. This is what you are seeing here: GDB cannot undo the effects
of the optimizer, so it does the best it can.


If you don't like this, then have a look at section "Debugging - Tips
and Tricks" in our documentation at
http://www.denx.de/twiki/bin/view/DULG/DebuggingTricks


Note that code size and performance will suffer from such mods.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Man is the best computer we can put aboard a spacecraft ...  and  the
only one that can be mass produced with unskilled labor.
                                                 -- Wernher von Braun