[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Simulavr-devel] Still more on gdb parameter reporting
From: |
ken restivo |
Subject: |
[Simulavr-devel] Still more on gdb parameter reporting |
Date: |
Thu, 31 Jan 2002 17:09:49 -0800 |
User-agent: |
Mutt/1.3.25i |
-----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-----
- [Simulavr-devel] Still more on gdb parameter reporting,
ken restivo <=