Re: [Simulavr-devel] erroneous offset in rjmp and rcall

[ken restivo]

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

FWIW, I have had the same exact problem, and I reported it on the avrgcc list, 
because it wasn't a bug in the simulator but rather (I thought) in the compiler.

The generated assembly code had an offset that was clearly absurd, and the 
simulator was just trying to do as it was instructed.

http://avr.jpk.co.nz/pipermail/avr-gcc-list/2002-August/004977.html

Anyway, I changed the optimization level in avrgcc, and the problem went away. 
Unfortunately, I didn't have time to isolate it down to a small sample program 
to reproduce the problem. And of course I still don't. It could have been 
caused by a bug in my program anyway.

- -ken
- -------
On Thu, Sep 19, 2002 at 05:39:03PM -0700, Theodore A. Roth wrote:
> What does `avr-objdump -h -S sos` say for the code in question?
> 
> Are you sure that the .text section is < 8 KB?
> 
> Is there any chance you could send me a simple program which demonstrates
> the problem?
> 
> Ted Roth
> 
> On Thu, 19 Sep 2002, eban wrote:
> 
> :) Hello everybody!!!
> :)
> :) I'm new to this atmel technology and I'm trying to
> :) simulate a smart card operative system called SOSSE
> :) (http://www.franken.de/users/mbsks/sosse/).
> :)
> :) In general everything seems all right but I have
> :) experienced some problems.
> :)
> :) The compilation seems to be all right, and i think
> :) SOSSE has been used before without problems. So I
> :) suspect the problem is in your simulator.
> :)
> :) im using simulavr version 0.1.1
> :)
> :) Let me show you the debug session with gdb. Running
> :) simulavr alone produces the same errors:
> :) ERROR: file storage.c: line 101: address out of
> :) bounds: 0xffffd550
> :)
> :) (gdb) disassemble 0x4C 0x52
> :) Dump of assembler code from 0x4c to 0x52:
> :) 0x4c <.zero_bss_start+2>:  cpc     r27, r18
> :) 0x4e <.zero_bss_start+4>:  brne    .-8             ; 0x48
> :) 0x50 <.zero_bss_start+6>:  rjmp    .-2818          ; 0xfffff550
> :) End of assembler dump.
> :)
> :) As you can see the rjmp goes to an invalid adress. (im
> :) using at90s8515)
> :) In the source code this instruction was in libc's
> :) (avr-libc-20020203) gcrt1.S from Marek Michalkiewicz
> :) et al:
> :) ....
> :) #if XRAMEND > 0x100
> :)    cpc     XH, r_tmp1      ; hi8(__bss_end)
> :) #endif
> :)    brne    .zero_bss_loop
> :)    XJMP    _U(main)
> :) ....
> :)
> :) in the included file macros.inc is defined:
> :) ....
> :) #define CONCAT1(a, b) CONCAT2(a, b)
> :) #define CONCAT2(a, b) a ## b
> :) #define _U(x) CONCAT1(__USER_LABEL_PREFIX__, x)
> :) ....
> :)
> :) and you can also find in this file:
> :) ....
> :) #if FLASHEND > 0x2000  /* ATmega */
> :)   #define XJMP jmp
> :)   #define XCALL call
> :) #else
> :)   #define XJMP rjmp
> :)   #define XCALL rcall
> :) #endif
> :) ....
> :)
> :) I don't understand that a ## b notation but i think it
> :) works for the assembler.
> :) So instead of jumping to main (0x1550) it's jumping
> :) somewere else (0xff...) or at least that's the way the
> :) simulator interprets the instruction.
> :)
> :) I compiled a much simpler program with the same
> :) compilation parameters and I didn't find this problem.
> :) The problem seems to be the way you manage the rjmp
> :) and rcall instructions when the offsets are large.
> :)
> :) If you see the binary file with hexedit you can see
> :) that the instruction is well assembled:
> :)    avr-objcopy -O binary sos sos.bin
> :)    hexedit sos.bin
> :) ....
> :) 00000050   7F CA  (the bytes are reversed)
> :) ....
> :)
> :) (0x50 is the offset of the rjmp to main)
> :) (the C is part of the opcode for rjmp. Cxxx)
> :)
> :) the jump that should be there is of (1550h-52h)/2 =
> :) A7Fh so you can see it was well assembled if the data
> :) was spected to be unsigned.
> :)
> :) It's very likely that you have a sign conversion
> :) problem or sign extension problem or something
> :) similar. It makes no sense to move to that address
> :) when the code words are in total 8K.
> :)
> :) the same problem occurs with rcall.
> :)
> :) best regards,
> :) Alberto Escalante
> :)
> :)
> :)
> :)
> :)
> :)
> :)
> :)
> :)
> :)
> :)
> :)
> :)
> :)
> :)
> :) __________________________________________________
> :) Do you Yahoo!?
> :) New DSL Internet Access from SBC & Yahoo!
> :) http://sbc.yahoo.com
> :)
> :)
> :) _______________________________________________
> :) Simulavr-devel mailing list
> :) address@hidden
> :) http://mail.freesoftware.fsf.org/mailman/listinfo/simulavr-devel
> :)
> 
> 
> 
> _______________________________________________
> Simulavr-devel mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/simulavr-devel

- -- 
- ---------------
The world's most affordable web hosting.
http://www.nearlyfreespeech.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9iz8Qe8HF+6xeOIcRAq+uAKCZbYbPKdMmhTeIFw7xl+Qj0fW+nQCdHV3r
QKSNgA36HOUxvE4V/5Xs2F8=
=A4A/
-----END PGP SIGNATURE-----