Re: Soft floating point emulation problems

[Richard Earnshaw <rearnsha at arm dot com>]

> >1) Are you sure these are really instructions in the code, and not
> >constants in constant pools?  The latter is quite probable, and the
> >disassembler can't tell this (find the object file containing this
> >instructions, compile the file to assembly and look for the same
> >instructions in the output file).
> 
> - Yes, there is code at this location.
> ...
>  270:   ea0000ac        b       2b8 <__cbrt+0x2b8>
>  274:   3fc29801        swicc   0x00c29801
>  278:   e893366d        ldmia   r3, {r0, r2, r3, r5, r6, r9, sl, ip, sp}
>  27c:   3fe91e2a        swicc   0x00e91e2a
>  280:   6fe7e984        swivs   0x00e7e984
>  284:   bffd5ae6        swilt   0x00fd5ae6
>  288:   cfa20f0c        swigt   0x00a20f0c
>  28c:   40039350        andmi   r9, r3, r0, asr r3
>  290:   adad51ec        stfges  f5, [sp, #944]!
>  294:   c000eb82        andgt   lr, r0, r2, lsl #23
>  298:   77cd8d5d        undefined
>  29c:   3ff8218d        swicc   0x00f8218d
>  2a0:   de9028b4        mrcle   8, 4, r2, cr0, cr4, {5}
>  2a4:   3fd6b69c        swicc   0x00d6b69c
>  2a8:   ba168ff2        blt     5a4278 <__cbrt+0x5a4278>
>         ...
>  2b8:   e91babf0        ldmdb   fp, {r4, r5, r6, r7, r8, r9, fp, sp, pc}
> ....

No, that's data, not code (at least, not between the first 'b' instruction 
and the 'ldmdb' instruction).  Note the undefined instruction.  What you 
are looking at is a small pool of data in the text section that is 
pc-relative addressable.  The disassembler can't tell where the embedded 
data sections are, so it tries to disassemble them.

R.

Note, there was a small (non-critical) buglet in gcc-2.95 which meant that 
constant pools were not always placed after the final return instruction, 
what you see above is a branch around a constant pool from the last part 
of the code to the return instruction sequence.  It has a small impact on 
performance, but that data will never be executed as code.  The problem 
was fixed in gcc-3.0