arm-coff stack & local variable display problems

arm-coff stack & local variable display problems

[Toralf Lund]

I'm trying to debug an arm-coff application using arm-coff-insight and a 
"BDI-2000" JTAG debug interface connected to an ARM-9 board (setup 
discussed briefly earlier.)

Many things work, but View->Stack or "where" in console sometimes fail 
to display correct call stack, and when they do "up" and "down" won't 
work correctly, either. For instance, at one point early in the init 
phase, the real call stack is:

#0 SlaveSerial
#1 hardware_init_hook
#2 start

Insight never displays it that way, however, and as I execute statements 
using Next (step over - I never "step into" subroutines in this case), 
the output changes. E.g. on one case, I got the following sequence:

#1  SlaveSerial (flash_start_addr=0x9ffd77c, flash_end_addr=0x801ac20) 
at mc9328xapp502.c:227
#1  0x08008410 in hardware_init_hook () at scu_fb.c:321
#2  0x0800da14 in InitKbd () at mc9328io.c:98

#0  SlaveSerial (flash_start_addr=0x9ffd76c, flash_end_addr=0x801afc2) 
at mc9328xapp502.c:244
#1  0x08008410 in hardware_init_hook () at scu_fb.c:321
#2  0x0800cc0c in IORead (addr=0x9ffd76c) at mc9328xapp502.c:115

#0  SlaveSerial (flash_start_addr=0x9ffd76c, flash_end_addr=0x21c11c) at 
mc9328xapp502.c:247

#0  SlaveSerial (flash_start_addr=0x9ffd76c, flash_end_addr=0x21c11c) at 
mc9328xapp502.c:264
#1  0x0800cd60 in SlaveSerial (flash_start_addr=0x9ffd76c, 
flash_end_addr=0x21c11c) at mc9328xapp502.c:253
#2  0x0800cb60 in IOWrite (addr=0x9ffd76c, data=33) at mc9328xapp502.c:99

#0  SlaveSerial (flash_start_addr=0x9ffd76c, flash_end_addr=0x21c026) at 
mc9328xapp502.c:275
#1  0x0800cd94 in SlaveSerial (flash_start_addr=0x9ffd76c, 
flash_end_addr=0x21c026) at mc9328xapp502.c:265
#2  0x0800cc0c in IORead (addr=0x9ffd76c) at mc9328xapp502.c:115

#0  SlaveSerial (flash_start_addr=0x9ffd76c, flash_end_addr=0x2ffff) at 
mc9328xapp502.c:275
#1  0x0800d7d0 in ShiftDataOut (Data16=2559) at mc9328xapp502.c:394
#2  0x0800ce50 in ShiftDataOut (Data16=2559) at mc9328xapp502.c:312

#0  SlaveSerial (flash_start_addr=0x9ffd76c, flash_end_addr=0x801ac28) 
at mc9328xapp502.c:277
#1  0x0800cdec in SlaveSerial (flash_start_addr=0x9ffd76c, 
flash_end_addr=0x801ac28) at mc9328xapp502.c:276
#2  0x0800cc0c in IORead (addr=0x9ffd76c) at mc9328xapp502.c:115

Note that InitKbd() is a routine called sometime before SlaveSerial(), 
while IORead(), IOWrite() and ShiftDataOut() are called from it, and 
there may possibly be some sort of correlation between their call and 
the point where they appear in the stack listing (but I'm *not* in them 
at the time.)

Also, local variables and function call parameters are sometimes not 
correctly displayed. Actually, you can tell that by looking at paramter 
values in the above stack trace.

Any ideas why this happens? Notice that I'm looking at code executed 
*before* main(). Is there any reason why the debugger shouldn't work 
correctly in that case?

I've tried version 5.3 and 6.0 of insight, with the same result. 6.1 is 
not tested yet, but I know that has other issues that prevents me from 
using it.

- Toralf

Re: arm-coff stack & local variable display problems

[Keith Seitz]

On Thu, 2004-04-29 at 04:29, Toralf Lund wrote:

> Any ideas why this happens? Notice that I'm looking at code executed 
> *before* main(). Is there any reason why the debugger shouldn't work 
> correctly in that case?

Has the stack been properly set up? If not, stack browsing is never
going to work.

Keith

Re: arm-coff stack & local variable display problems

[Toralf Lund]

Keith Seitz wrote:

>On Thu, 2004-04-29 at 04:29, Toralf Lund wrote:
>
>  
>
>>Any ideas why this happens? Notice that I'm looking at code executed 
>>*before* main(). Is there any reason why the debugger shouldn't work 
>>correctly in that case?
>>    
>>
>
>Has the stack been properly set up? If not, stack browsing is never
>going to work.
>  
>
Well, that depends on what exactly "properly" means in this context. 
Yes, the stack pointer has been initialised, but if there are other 
requirements, the start routine may well fail to meet those. I'm using 
the basic crt0.S from "newlib" with a few additions of my own...

>Keith
>
>  
>

Re: arm-coff stack & local variable display problems

[Toralf Lund]

Keith Seitz wrote:

>On Thu, 2004-04-29 at 04:29, Toralf Lund wrote:
>
>  
>
>>Any ideas why this happens? Notice that I'm looking at code executed 
>>*before* main(). Is there any reason why the debugger shouldn't work 
>>correctly in that case?
>>    
>>
>
>Has the stack been properly set up? If not, stack browsing is never
>going to work.
>  
>
Maybe I forgot to mention this earlier: I found one problem with the 
application that seemed to have caused these problems at least in part: 
There were "endianness" setup issues. The program was compiled for 
big-endian, the appropriate hardware pin was set up for big-endian 
operation, and the debug pod was configured for big-endian mode. The 
"big-endian" flag in the control coprocessor (CP15) was, however, not 
set; I actually had the appropriate code all along, but it was left out 
by mistake on the debug setup. (This lead to a surprisingly low number 
of problems with the actual execution of the code, since it would mostly 
do word accesses anyway.)

After this problem was resolved, the variable display is more or less 
OK, and the stack looks good most of the time - although I'm still 
having problems e.g. stepping up from deeply nested routines, in 
particular "I/O implementation" calls that are accessed via the C lib.

- Toralf