[Simulavr-devel] Still more on gdb parameter reporting

[ken restivo]

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

couldn't put the mystery down. plus, it gives me time to procrastinate from 
what i am supposed to be doing ;-)

before the call:

r0             0x2      2 '\002'
r1             0x0      0 '\000'
r2             0x0      0 '\000'
r3             0x0      0 '\000'
r4             0x0      0 '\000'
r5             0x0      0 '\000'
r6             0x0      0 '\000'
r7             0x0      0 '\000'
r8             0x0      0 '\000'
r9             0x0      0 '\000'
r10            0x0      0 '\000'
r11            0x0      0 '\000'
r12            0x0      0 '\000'
r13            0x0      0 '\000'
r14            0x0      0 '\000'
r15            0x0      0 '\000'
r16            0x79     121 'y'
r17            0x0      0 '\000'
r18            0x0      0 '\000' (stackSize)
r19            0x0      0 '\000'
r20            0x69     105 'i'  (funk)
r21            0x0      0 '\000'
r22            0xa      10 '\n'  (pri)
r23            0x0      0 '\000'
r24            0x79     121 'y'  (thr)
r25            0x0      0 '\000'
r26            0x79     121 'y'
r27            0x0      0 '\000'
r28            0x5f     95 '_'
r29            0x2      2 '\002'
r30            0x81     129 '\201'
r31            0x0      0 '\000'
SREG           0x0      0 '\000'
SP             0x25f    607
PC             0x142    322

0x00000142      56              calledFunc(kth, 10, th2, 0);


- -------------
after the call:
r0             0x2      2 '\002'
r1             0x0      0 '\000'
r2             0x0      0 '\000'
r3             0x0      0 '\000'
r4             0x0      0 '\000'
r5             0x0      0 '\000'
r6             0x0      0 '\000'
r7             0x0      0 '\000'
r8             0x0      0 '\000'
r9             0x0      0 '\000'
r10            0x0      0 '\000'
r11            0x0      0 '\000'
r12            0x0      0 '\000'
r13            0x0      0 '\000'
r14            0x0      0 '\000'
r15            0x0      0 '\000'
r16            0x79     121 'y'  (garbage)
r17            0x0      0 '\000'
r18            0xa      10 '\n'  (where pri is now)
r19            0x0      0 '\000'
r20            0x69     105 'i'  (garbage)
r21            0x0      0 '\000'
r22            0x69     105 'i'  (where funk is now)
r23            0x0      0 '\000'
r24            0x79     121 'y'  (garbage)
r25            0x0      0 '\000'
r26            0x79     121 'y'
r27            0x0      0 '\000'
r28            0x5c     92 '\\'
r29            0x2      2 '\002'
r30            0x79     121 'y'  (where thr is now)
r31            0x0      0 '\000'
SREG           0x0      0 '\000'
SP             0x25c    604
PC             0x8e6    2278

calledFunc(thr=0x79, pri=121, address@hidden: 0x14 <.__start_of_init__+20>, 
stackSize=10)

how did all this get moved around? i had a look at the disassembly of 
calledFunc's preamble, which looks like this in my "real" program:
 8d8:   1f 93           push    r17
 8da:   f9 2f           mov r31, r25
 8dc:   e8 2f           mov r30, r24
 8de:   26 2f           mov r18, r22
 8e0:   37 2f           mov r19, r23
 8e2:   75 2f           mov r23, r21
 8e4:   64 2f           mov r22, r20

so... it looks like avr-as is rearranging deck chairs on the titanic (my 
program ;-). note how r22/23 went from 0x0a to 0x69, but gdb is still looking 
for the parameters in their old location (i.e. descending neatly in reverse 
order from r24/25 to r18/19)? 

and the 121 that it reports for pri is suspiciously like the 0x79 in r24/25... 

and the 0xa/0x14 for funk and the 10 for stackSize is also suspiciously like 
the 10 that was supposed to go into pri... and was passed in to r22/23 and then 
moved to r18/19, as if gdb is reading from r18/19 (where the value for 
stackSize *used* to be... and it was 0x0) instead of from nowhere... stackSize 
isn't used in this function at all, so avr-gcc and friends have optimized it 
out. r18/19 get clobbered, and the values there aren't meaningful in the 
context of the passed parameters.

in the case of funk showing up as 0xa, i have no idea. it looks like it's just 
reading from the wrong place, from r18/19, instead of from r20/21 (where it 
used to be) or r22/23 (where it has been moved to by the preamble).

all this jockeying around may explain why the test program doesn't fail quite 
so spectacularly or consistently: the test functions are empty and the 
toolchain isn't moving registers around so wantonly.

this is all a long way of saying: is there some way to get simulavr to report 
the values of passed parameters to gdb IMMEDIATELY after the rcall/call 
instruction, and before all this moving-aroung-of-registers has been done by 
avr-as? or for it to track all this shuffling a little more closely? i have to 
guess that the i386/68k/mips/mipsel/ppc/sh/sparc/arm/etc guys have been through 
this wringer before, there has to be some solution.

ok, my brain hurts now. going back to what i was doing before...

- -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

iD8DBQE8Werce8HF+6xeOIcRAmNPAKDGZvNC6vZYdcGBwYjaaDk+itvoswCgmj2L
FZkH/gQmdHaHTgMF4jLT+i4=
=Z5qG
-----END PGP SIGNATURE-----