simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simulavr-devel] Still some gdb display issues


From: Theodore A. Roth
Subject: Re: [Simulavr-devel] Still some gdb display issues
Date: Thu, 31 Jan 2002 18:10:07 -0700 (MST)

I don't see a problem when I run the test program you sent me:

Breakpoint 1, main (argc=0, argv=0x0) at bug.c:52
52          ith = malloc(sizeof(struct teststruct));
(gdb) n
54          outp(0xFF, DDRD);
(gdb) 
56          calledFunc(ith, 0, idler, 0);
(gdb) p ith
$3 = (struct teststruct *) 0x63
(gdb) s

Breakpoint 2, calledFunc (thr=0x63, pri=0, address@hidden: 0x56 <idler>, 
    stackSize=0) at bug.c:42
42          outp('C', PORTD); 
(gdb) p thr
$4 = (struct teststruct *) 0x63
(gdb) 

I'm looking at the memory with disp and everything looks fine. I also 
tried compiling with -O2 and don't see the problem.

I'm using gcc-3.0.2 and avr-libc-20011126. I don't think that this would 
make a difference though.

Can you send me the .elf, .lst, .c and Makefile for the test program you 
sent me?

Are you using a clean gdb-5.1 with the pre9 patch?

Ted Roth



On Thu, 31 Jan 2002, ken restivo wrote:

:)Hmm. I noticed one more bit of strangeness:
:)
:)41              calledFunc(ith, 0, idler, 0);
:)2: /x $PC = 0x86
:)1: /x $SP = 0x25f
:)(gdb) p ith
:)$1 = (struct teststruct *) 0x67
:)(gdb) p idler
:)$2 = {void ()} 0x56 <idler>
:)(gdb) s
:)calledFunc (thr=0x63, pri=0, address@hidden: 0x56 <idler>, stackSize=0)
:)
:)Basically, ith is really at 0x63, but shows up wrong in the caller!
:)Once it gets into the called func, it is correctly reported as 0x63.
:)Bizarre.
:)
:)Also, in my real program, the bug is still there just as much as ever:
:)lots of garbage data in passed params. The fix seems not to have fixed
:)it at all, actually. The test program looks fine except for the 0x67
:)!= 0x63 anomaly.
:)
:)Sorry about that. Anyway, I am right now debugging my real program
:)with disp, counting bytes in the SRAM display and looking at
:)registers. A useful exercise, but pretty slow going. disp kicks ass,
:)but gdb really would be even better ;-).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]