Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiling with WINAVR produces incorrect object code. #302

Open
WestfW opened this issue Jan 12, 2021 · 0 comments
Open

Compiling with WINAVR produces incorrect object code. #302

WestfW opened this issue Jan 12, 2021 · 0 comments
Assignees
Labels
Maintainability Fixing this should improve the readablity/maintainabiity of Optiboot. Regression Something that used to work has become broken. Type-Defect Confirmed to be an actual bug.

Comments

@WestfW
Copy link
Member

WestfW commented Jan 12, 2021

The WinAVR version of avr-gcc is very old (2010, gcc version 4.3.3), and compiles the current optiboot sources into an object file that is larger than 512 bytes (for the standard compile options.)
In theory, BIGBOOT versions would still be useful, especially on
But it was ALSO recently found to create different and incorrect code when trying to deal with the somewhat odd union that optiboot uses to deal with the non-compiler-allocated buffer:

https://www.avrfreaks.net/forum/optiboot-atmega-128a-over-rs485

`Atmel standard (v5.4 based) toolchain:

  // read a page worth of contents
  bufPtr = buff.bptr;

1fd10: 81 2c mov r8, r1 ;;; r9:r8 = 0x100 (RAMSTART)
;;; which was what we wanted.
1fd12: 99 24 eor r9, r9 ;;; (even if it's a bit weird)
1fd14: 93 94 inc r9

  do *bufPtr++ = getch();

1fd16: 7a d0 rcall .+244 ; 0x1fe0c
1fd18: f4 01 movw r30, r8
1fd1a: 81 93 st Z+, r24
1fd1c: 4f 01 movw r8, r30
1fd1e: f1 e0 ldi r31, 0x01 ; 1
while (--length);
1fd20: af 1a sub r10, r31
1fd22: b1 08 sbc r11, r1
1fd24: c1 f7 brne .-16 ; 0x1fd16 <main+0x112>

4.3.3:

;;; r6 is used as a global register coopy of "buffer"
;;; (loaded somewhat early in the code)
1fc8c: 60 90 00 01 lds r6, 0x0100 ;;; r6 is supposed to be 0x100,
1fc90: 70 90 01 01 lds r7, 0x0101 ;;; but gets @ 0x100 instead!

// later ...
1fd3c: 83 01 movw r16, r6 ;;; get buff from r6
// read a page worth of contents
bufPtr = buff.bptr;
do *bufPtr++ = getch();
1fd3e: 7e d0 rcall .+252 ; 0x1fe3c
1fd40: f8 01 movw r30, r16
1fd42: 81 93 st Z+, r24
1fd44: 8f 01 movw r16, r30
while (--length);
1fd46: 21 97 sbiw r28, 0x01 ; 1
1fd48: d1 f7 brne .-12 ; 0x1fd3e <main+0x124>
`

I feel like I should look for a workaround for this.

@WestfW WestfW self-assigned this Jan 12, 2021
@WestfW WestfW added Maintainability Fixing this should improve the readablity/maintainabiity of Optiboot. Regression Something that used to work has become broken. Type-Defect Confirmed to be an actual bug. labels Jan 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Maintainability Fixing this should improve the readablity/maintainabiity of Optiboot. Regression Something that used to work has become broken. Type-Defect Confirmed to be an actual bug.
Projects
None yet
Development

No branches or pull requests

1 participant