simulavr-devel
[Top][All Lists]
Advanced

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

[Simulavr-devel] possible sim bug?


From: ken restivo
Subject: [Simulavr-devel] possible sim bug?
Date: Tue, 29 Jan 2002 19:39:10 -0800
User-agent: Mutt/1.3.25i

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

might take me a while to get to the regression stuff. 

i'm still tracking down an odd anomaly: might be simulavr, or it might be my 
fault.

i'm calling a function from caller():
        57              called_function(&ith, 0, idler, 0);
        3: idler = {void ()} 0x8e8 <idler>

when stepping into it:
        called_function (thr=0x252, pri=594, funk=0, stackSize=0) at 
kthreads.c:30

ok, something is screwy. the first three arguments look fine in the caller, but 
are mangled as soon as they arrive in the called function.  pri should be 0, 
and funk should be 0x8e8, etc.

gcc has optimized out the symbol ith, despite its having been declared 
volatile, since its only use is to pass it in to this function. so, gdb says it 
doesn't exist. 

however, just before the rcall, all the registers look right. register r24/25 
contains a sane value for "ith" (i.e. 0xA7). r22/23 are zero, as expected. the 
value for idler, r20/21 is 0x474, which is the correct value of idler << 1.  i 
wish it used unsigned numbers, but other than that, everything looks sensible.

in any case, the disassembly looks like:
    called_function(ith, 0, idler, 0);
 90e:   20 e0           ldi r18, 0x00   ; 0
 910:   30 e0           ldi r19, 0x00   ; 0
 912:   44 e7           ldi r20, 0x74   ; 116
 914:   54 e0           ldi r21, 0x04   ; 4
 916:   73 2f           mov r23, r19
 918:   62 2f           mov r22, r18
 91a:   66 df           rcall   .-308       ; 0x7e8

all normal, and all using opcodes that are (were?) known to work in simulavr. 
bizarre.

when stepping into the called function, same thing, the registers look right. 
but gdb reports stuff that doesn't make sense.

y the way, i know that the problem is "really" there, and not just gdb 
reporting stuff incorrectly, because it shows up in the execution of the 
program. when funk() is executed, simuavr jumps to memory location 0x0, and 
basically resets and starts from main all over again. 

just an fyi. i'm working on distilling it down to a test program, which i will 
either help me fix it, or i'll send it along if i can't.

- -ken

- -- 
- ------------------
One world. Many gods. Plenty for everyone.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD4DBQE8V2rde8HF+6xeOIcRAuSdAJikSvd133UpQzYRLcN+HAYX5CeuAJ947BuO
q5NgM693gNCmqC1RBLV86A==
=H/3T
-----END PGP SIGNATURE-----



reply via email to

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