avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [avr-libc-dev] LPM instructionsin optimized code causes unintended b


From: Weddington, Eric
Subject: RE: [avr-libc-dev] LPM instructionsin optimized code causes unintended behavior in execution
Date: Thu, 17 Jun 2010 21:14:53 -0600

 

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Wouter van Gulik
> Sent: Thursday, June 17, 2010 1:18 PM
> To: address@hidden
> Subject: Re: [avr-libc-dev] LPM instructionsin optimized code 
> causes unintended behavior in execution
> 
> On 17/06/10 10:15, Thomas Carsten Franke wrote:
> > Am 17.06.2010 09:38, schrieb Wouter van Gulik:
> >    
> >> Wouter van Gulik schreef:
> >>      
> >>> Joerg Wunsch schreef:
> >>>        
> >>>> As Wouter van Gulik wrote:
> >>>>
> >>>>          
> >>>>>> IMHO, the respective code is hand-crafted asm code in avr-libc.
> >>>>>>              
> >>>>> Are you sure? The code is about a jump table, is that 
> in avr-libc?
> >>>>>            
> >>>> Errm, you are right...
> >>>>          
> >>> We should probably file a bug report at binutils as well. gas is
> >>> excepting an 'illegal' instruction. This could mean gcc/gas also
> >>> happily generates the undefined LD files?
> >>>
> >>>        
> > Just right now I added a problem report to gcc 4.3.3 
> version describing
> > the problem.
> 
> Just for the record the gcc bug id is:44564  
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44564
> I think this is a nasty bug, but it is hard to recreate the 
> problem. I 
> did a quick scan of GCC but I can't find a reference to a lpm r?, Z+ 
> other than those to __temp_reg__.

Thanks for the bug ID. You can put me on the CC list of any bug.

In a bug comment I asked for the generated assembly output from using 
-save-temps. This is important because there is another bug in the 
*disassembler*; IIRC, it spits out an "LPM r, Z+", when in reality it is an 
"LPM r, Z". That disassembler bug is not fixed yet.

As a matter of fact.... (checking code and instruction set)

The code you have in the bug report shows:
5808:       f4 91           lpm     r31, Z+

Take a long hard look at the hex instruction. Reverse the bytes: 91 F4

The LPM instruction in the instruction set document (page 91) shows this is 
Form 2 (ii) of the LPM instruction which is "LPM, r, Z", which is without the 
plus sign. Therefore this is not undefined. You've just rediscovered a 
different bug in binutils.

Eric Weddington



reply via email to

[Prev in Thread] Current Thread [Next in Thread]