[Top][All Lists]
[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 ;-).