llvm dev - Nov 2011 - [LLVMdev] Thumb-2 code generation error in Apple LLVM at all optimization levels

On Fri, Nov 11, 2011 at 5:26 PM, Owen Anderson <resistor at mac.com>
wrote:
> This is not quite right.  It does have a 12-bit immediate field, but it is
decomposed into an 8-bit base immediate and a 4-bit right-rotate value.  Your
example of #4000 is encoded as a base value of 0xfa and a rotate of 0xe, which
is correct.
>
>> I don't know what the "it hs" instruction does.  I
suspect that's
>> where the problem lies, but "it" is a very common word, and
"hs" is
>> quite common as well, as it is a frequent mispelling for
"has".
>> Perhaps someone who knows Thumb-2 assembly better than I do could
>> comment.
>
> The IT instruction is how you express predication in Thumb2.  Unlike ARM
instructions, where the predicate is part of the instruction, Thumb2
instructions use IT to set the predicates for following instructions.  In this
case, it applies the "hs" predicate to the subsequent call to _usleep.
 I'd have to double check, but I'm fairly confident that the hs
condition code is equivalent to >= for integers.
All of my regression testing so far has had my speed slider set to its
maximum, so the useconds_t has always been precisely zero.

Maybe there's something special about zero that would not be the case
for an integer ranging from 1 to 3999.

I'll check that out, but not right now, I'm about to pass right out,
but I don't want to because I am even more hungry than I am tired.

There is a pizza joint within walking distance of my apartment.  I'm
going to go stuff myself silly.



-- 
Don Quixote de la Mancha
Dulcinea Technologies Corporation
Software of Elegance and Beauty
http://www.dulcineatech.com
quixote at dulcineatech.com

I am thinking now that the Thumb-2  machine code generated by Apple's
LLVM 3.0+svn compiler is correct, but that when a Release build is
generated, the use of conditional machine instructions confuses GDB.

I boiled my apparently erroneous source down to:

- (void) mySleep: (int)sleepTime
{
    if ( sleepTime >= 4000 ){
        usleep( sleepTime );
    }

    return;
}

If I set a breakpoint on the usleep call, the breakpoint will be hit
but usleep() will not actually be called.

I verified this by passing in 5000.  When I do, I can step down into
the shared libraries that lead to the actual system call.

 I have also tried calling a regular subroutine of my own instead of a
system call.  When sleepTime is zero, my subroutine is not called even
though GDB shows my program stepping over the subroutine call.

I would say that this is a bug in GDB's source code debugger, in that
it ought to consider the basic block of the if only to be entered if
the test succeeds.  GDB's assembly code debugger does the right thing.

In any case this is not a bug in LLVM.  If it is to be considered a
bug in GDB it would be really hard to fix.


-- 
Don Quixote de la Mancha
Dulcinea Technologies Corporation
Software of Elegance and Beauty
http://www.dulcineatech.com
quixote at dulcineatech.com

Le 13 nov. 2011 à 11:19, Don Quixote de la Mancha a écrit :
> I am thinking now that the Thumb-2  machine code generated by Apple's
> LLVM 3.0+svn compiler is correct, but that when a Release build is
> generated, the use of conditional machine instructions confuses GDB.
> 
> I boiled my apparently erroneous source down to:
> 
> - (void) mySleep: (int)sleepTime
> {
>    if ( sleepTime >= 4000 ){
>        usleep( sleepTime );
>    }
> 
>    return;
> }
> 
> If I set a breakpoint on the usleep call, the breakpoint will be hit
> but usleep() will not actually be called.
> 
Debugging info in optimized build are not reliable.
The compiler reorder instructions, change the program flow, and do a lot of
other transformation that alter them.
> I verified this by passing in 5000.  When I do, I can step down into
> the shared libraries that lead to the actual system call.
> 
> I have also tried calling a regular subroutine of my own instead of a
> system call.  When sleepTime is zero, my subroutine is not called even
> though GDB shows my program stepping over the subroutine call.
> 
> I would say that this is a bug in GDB's source code debugger, in that
> it ought to consider the basic block of the if only to be entered if
> the test succeeds.  GDB's assembly code debugger does the right thing.
> 
> In any case this is not a bug in LLVM.  
Why not ? Generating valid debug info is the role of the compiler, not the
debugger.
> If it is to be considered a bug in GDB it would be really hard to fix.
-- Jean-Daniel