In message 1105544287.13808.449.camel@hr2600.symbium.com you wrote:
I'm using ELDK 3.1 from which I installed support for the "arm-linux" target (not clearly documented I must say) which
What exactly is "not clearly documented"? I'd like to improve this.
...
00f88088 <__umodsi3>: f88088: 000051e3 andeq r5, r0, r3, ror #3 f8808c: 2900000a stmcsdb r0, {r1, r3} f88090: 010051e3 smlatteq r0, r3, r1, r5 f88094: 01005011 tsteq r0, r1, lsl r0 f88098: 0000a003 andeq sl, r0, r3 f8809c: 1eff2f31 mrcne 15, 7, r2, cr15, cr1, {1} f880a0: 0130a0e3 teqeq r0, r3, ror #1 f880a4: 010251e3 smlatteq r2, r3, r1, r5 f880a8: 00005131 andeq r5, r0, r1, lsr r1 f880ac: 0112a031 tsteq r2, r1, lsr r0 f880b0: 0332a031 teqeq r2, #49 ; 0x31 f880b4: faffff3a blx f87da4 <srec_decode+0xbc> f880b8: 020151e3 andeq r5, r1, #-1073741768 ; 0xc0000038 f880bc: 00005131 andeq r5, r0, r1, lsr r1 f880c0: 8110a031 tsthi r0, r1, lsr r0 f880c4: 8330a031 teqhi r0, #49 ; 0x31 f880c8: faffff3a blx f87db8 <srec_decode+0xd0> f880cc: 0020a0e3 eoreq sl, r0, r3, ror #1 f880d0: 010050e1 smlatteq r0, r1, r0, r5 f880d4: 01004020 tsteq r0, r0, lsr #32 f880d8: a10050e1 smlattge r0, r1, r0, r5
Note that a large number of instructions have the "condition" field (bits 28-31)set to EQ - not a common occurrence in "real" code. Most "real" code has this field set to AL (always or unconditional.)
This is probably a bug with by objdump; I see the same here when disassembling the "u-boot" ELF file:
00f8e348 <__umodsi3>: f8e348: 000051e3 andeq r5, r0, r3, ror #3 f8e34c: 2900000a stmcsdb r0, {r1, r3} f8e350: 010051e3 smlatteq r0, r3, r1, r5 f8e354: 01005011 tsteq r0, r1, lsl r0 f8e358: 0000a003 andeq sl, r0, r3 f8e35c: 1eff2f31 mrcne 15, 7, r2, cr15, cr1, {1} f8e360: 0130a0e3 teqeq r0, r3, ror #1 f8e364: 010251e3 smlatteq r2, r3, r1, r5 f8e368: 00005131 andeq r5, r0, r1, lsr r1 f8e36c: 0112a031 tsteq r2, r1, lsr r0 f8e370: 0332a031 teqeq r2, #49 ; 0x31 f8e374: faffff3a blx f8e064 <srec_decode+0xbc>
But obviously it makes no sense to have a reference to srec_decode in a divide routine. And when looking at the object file this looks like this:
-> arm-linux-objdump -D lib_arm/_umodsi3.o
lib_arm/_umodsi3.o: file format elf32-bigarm
Disassembly of section .text:
00000000 <__umodsi3>: 0: e3510000 cmp r1, #0 ; 0x0 4: 0a000027 beq a4 <Ldiv0> 8: e3a03001 mov r3, #1 ; 0x1 c: e1500001 cmp r0, r1 10: 31a0f00e movcc pc, lr
00000014 <Loop1>: 14: e3510201 cmp r1, #268435456 ; 0x10000000 18: 31510000 cmpcc r1, r0 1c: 31a01201 movcc r1, r1, lsl #4 20: 31a03203 movcc r3, r3, lsl #4 24: 3a000003 bcc 14 <Loop1>
...which matches the source code.
Seems to be some endianess problem in objdump or so...
[Maybe we should rename it into objdumb ;-) ]
This code is in the middle of "srec_decode".
And this doesn't make you nervous?
The code at __umodsi3 (0xf88088) looks like it was compiled for the Thumb instruction set. What's up with that??
This code is pulled in from this library: /opt/eldkarm31/usr/bin/../lib/gcc-lib/arm-linux/3.3.3/libgcc.a(_umodsi3.o)
Are you absolutely sure about this? I think it comes from lib_arm/_umodsi3.o !
This is part of the software floating point support for IXP425.
No, this has nothing to do with FP support. It's a simple division routine.
Best regards,
Wolfgang Denk