Incorect disassembly in .lss file [AS6 bug]

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using Atmel Studio 6, including the latest patches.

avr-gcc --version gives:

avr-gcc.exe (AVR_8_bit_GNU_Toolchain_3.3.0_364) 4.5.1
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The .lss file contains some lines like this:

    3ee0:	8b e7       	ldi	r24, 0x7B	; 123
    3ee2:	92 e9       	ldi	r25, 0x92	; 146
    3ee4:	86 a3       	lds	r24, 0x56
    3ee6:	97 a3       	lds	r25, 0x57

However, the Atmel Studio 6 disassembly shows:

00001F70  LDI R24,0x7B		Load immediate 
00001F71  LDI R25,0x92		Load immediate 
00001F72  STD Z+38,R24		Store indirect with displacement 
00001F73  STD Z+39,R25		Store indirect with displacement 

I looked through the AVR Instruction Set Manual and I believe that the STD Z is the correct interpretation of those bytes. This is backed up by the fact that an LDS on those two registers after loading data into them (with LDI) doesn't make sense.

Is this a known bug? I did a search of the forum but didn't find anything related.

EDIT: I'd like to be clear that the program is working as expected. Just the .lss file doesn't display the correct mnemonics for the emitted opcodes.

Jeff Nichols

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What does the .s file contain for that same sequence?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is no .s file; it's compiled from C.

Jeff Nichols

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is always an s file if you use gcc. Just don't delete it. You achieve this by means of -save-temps.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
There is no .s file; it's compiled from C.

No I mean use -save-temps and -fverbose-asm and look at the .s file that the C compiler creates and passes to avr-as to create the code in the first place.

Also which AVR - not a tiny4/5/9/10/20/40 by any chance?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
.LBB58:
	.loc 3 504 0
	ldi r24,lo8(-28037)
	ldi r25,hi8(-28037)
	std Z+38,r24
	std Z+39,r25

Jeff Nichols

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup and I just used a binary editor to edit the 8 bytes you showed into test.bin then tried:

E:\>avr-objdump -b binary -D -m avr test.bin

test.bin:     file format binary


Disassembly of section .data:

00000000 <.data>:
   0:   8b e7           ldi     r24, 0x7B       ; 123
   2:   92 e9           ldi     r25, 0x92       ; 146
   4:   86 a3           std     Z+38, r24       ; 0x26
   6:   97 a3           std     Z+39, r25       ; 0x27
        ...

Admittedly that is using WinAVR's avr-objdump not the one from Atmel. I'll try that next...

EDIT: guess what:

C:\Program Files\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.0.65\AVRToolchain\bin>avr-objdump -b binary -D -m av
r e:\test.bin

e:\test.bin:     file format binary


Disassembly of section .data:

00000000 <.data>:
   0:   8b e7           ldi     r24, 0x7B       ; 123
   2:   92 e9           ldi     r25, 0x92       ; 146
   4:   86 a3           lds     r24, 0x56
   6:   97 a3           lds     r25, 0x57
        ...

So it's an Atmel bug. I'll move this to the AS5/6 forum where their people will see it.

Last Edited: Thu. Nov 1, 2012 - 05:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's with -fverbose-asm too:

.LBB58:
	.loc 3 504 0
	ldi r24,lo8(-28037)	 ;  tmp59,
	ldi r25,hi8(-28037)	 ;  tmp59,
	std Z+38,r24	 ;  MEM[(struct TC0_t *)2560B].D.2736.PER, tmp59
	std Z+39,r25	 ;  MEM[(struct TC0_t *)2560B].D.2736.PER, tmp59

It's an xmega32a4u

Jeff Nichols

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Our posts crossed, my edit above:

Quote:
So it's an Atmel bug.

I have a feeling this may be something to do with the addition of tiny 4/5/9/10 to their binutils.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks. I only happened upon this by accident. I wanted to make sure a long chain of macros and inlines got compiled down to a literal 0x927B (and they did), and noticed the LDS on the next lines didn't make any sense.

Jeff Nichols

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your toolchain is very out of date - can you upgrade and try with 3.4.1 rather than 3.3.0? Open up the extension manager within AS6 and install any AS6 and toolchain patches that are available.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean,

But I've upgraded to "SP1" (build 1938). I thought that WAS the most up to date issue of AS6? Are you saying there's an issue of toolchain beyond this?

(I even checked "Help-check version" the other day and it said I was up to date).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your command line shows "3.4.0.65" which is the older 3.4.0 toolchain, there is a newer 3.4.1 available which is supposed to fix all the wonky TINY4/5/9/10 stuff.

pixel2001n's using the even older 3.3.0 release.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Then I'm very confused by Atmel's version management. I would have thought that the compiler was a pretty fundamental component of AS6 rather than an optional "extension". If something like VAssistX were out of date I would not fret too much - it's an "extension" - it doesn't matter if it's old and out of date - if I don't like what it's doing I urn it off. The compiler (IMAO) is not like that - it's a fundamental component of the build system. If it's out of date I expect "Help-check version" to tell me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The compiler (IMAO) is not like that - it's a fundamental component of the build system. If it's out of date I expect "Help-check version" to tell me.

People sometimes deliberately stick with an older compiler version, no matter how buggy, just to ensure a stable development environment for a product. The Help->Check for Updates is for AS6 itself only, work for alerting about out of date extensions is ongoing.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And that's their choice. However I'd still like Help-check updates to tell me!

BTW have Atmel forgotten to put 50p in the meter again? I'm downloading the update but it's about 0.01MB/s at present!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is Atmel updating every day now? I did a fresh install on this computer a few days ago to fix a bug with the ASF 3.4.1 not installing (which I'm not thrilled about either, BTW).

I did my due diligence. If Atmel can't get fixed versions to me after I've downloaded hours worth of updates and patches fresh from their (impossible to navigate) website, then it's no longer my fault.

I will try it, though if past history is any judge, it'll take me hours to get the updates.

Jeff Nichols

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The bug is still there.

My version was already the latest, but all the Atmel Studio and Framework and Toolchain installs have left my PATH a royal mess, so that's the source of the seemingly outdated versions.

Jeff Nichols