Hello people. I've been doing libgcc subset extraction for cortex m4(armv7e-m). I'm using gcc version 4.9.1. The basic methodology I'm using includes,
i- Build gcc and locate the armv7e-m/libgcc/libgcc.a fileii- Disassemble the libgcc.a file and search for the requisite functions like __aeabi_f2d(__extendsfdf2).iii- Perform cleanup and I'm done.
This has worked for most of the functions under consideration. However certain functions just don't seem to have a .text section. It must be noted that the .text section is where the important stuff happens, and this is what I want to extract. Like when I extracted __aeabi_l2f(__floatdisf) which is used for long long to single precision conversion, I got the disassembly which you can see in the attached document. Is it possible for functions to just be stubs and have no code whatsoever. This is rather anti-intuitive and difficult to comprehend. Can someone please give some explanation.
Thanks, Bilal
Is it possible for functions to just be stubs and have no code whatsoever.
For shared libraries, yes. You can, for example, generate place-holder libraries and expect the system executing the program to provide a library with the same name but with specific implementations of the functions. The placeholder provides to the compiler the name of the depending libraries.
However I do not know how libgcc.a is being used.
That said, the disassembly on my end returned :
$ armv7a-hardfloat-linux-gnueabi-objdump -d libgcc.a | grep -i __aeabi_f2d -A5000000304 <__aeabi_f2d>:304: e1b02080 lsls r2, r0, #1308: e1a011c2 asr r1, r2, #330c: e1a01061 rrx r1, r1310: e1a00e02 lsl r0, r2, #28314: 121234ff andsne r3, r2, #-16777216 ; 0xff000000318: 133304ff teqne r3, #-16777216 ; 0xff00000031c: 1221130e eorne r1, r1, #939524096 ; 0x38000000320: 112fff1e bxne lr324: e3320000 teq r2, #0328: 133304ff teqne r3, #-16777216 ; 0xff00000032c: 012fff1e bxeq lr330: e92d4030 push {r4, r5, lr}334: e3a04d0e mov r4, #896 ; 0x380338: e2015102 and r5, r1, #-2147483648 ; 0x8000000033c: e3c11102 bic r1, r1, #-2147483648 ; 0x80000000340: eaffff83 b 154 <__adddf3+0x148>00000344 <__aeabi_ul2d>:...
$ armv7a-hardfloat-linux-gnueabi-objdump -d libgcc.a | grep -i __aeabi_f2d -A50
00000304 <__aeabi_f2d>:
304: e1b02080 lsls r2, r0, #1
308: e1a011c2 asr r1, r2, #3
30c: e1a01061 rrx r1, r1
310: e1a00e02 lsl r0, r2, #28
314: 121234ff andsne r3, r2, #-16777216 ; 0xff000000
318: 133304ff teqne r3, #-16777216 ; 0xff000000
31c: 1221130e eorne r1, r1, #939524096 ; 0x38000000
320: 112fff1e bxne lr
324: e3320000 teq r2, #0
328: 133304ff teqne r3, #-16777216 ; 0xff000000
32c: 012fff1e bxeq lr
330: e92d4030 push {r4, r5, lr}
334: e3a04d0e mov r4, #896 ; 0x380
338: e2015102 and r5, r1, #-2147483648 ; 0x80000000
33c: e3c11102 bic r1, r1, #-2147483648 ; 0x80000000
340: eaffff83 b 154 <__adddf3+0x148>
00000344 <__aeabi_ul2d>:
...
I have the source of __aeabi_f2d, but the source of __aeabi_l2f was giving me problems. It was just a stub. However, I've solved this problem now by making a very simple application, building it with gcc using the appropriate flags, and then seeing the disassembly. I don't know why I wasn't able to extract sources by dissembling libgcc.a. The thing about the place-holder libraries is kinda new for me. Thanks for that
Well, libgcc.a is an AR archive, containing multiple libraries and object files at once. For example, if you do :
$ ar t libgcc.a
This will print a listing of all the object files contained in your version of libgcc.a
The libgcc.a that my system use during cross-compiling contains an object file named _arm_addsubsf3.o, which defines :
$ armv7a-hardfloat-linux-gnueabi-nm -a _arm_addsubsf3.o 00000000 n .ARM.attributes00000000 b .bss00000000 d .data00000000 N .debug_abbrev00000000 N .debug_aranges00000000 N .debug_info00000000 N .debug_line00000000 n .note.GNU-stack00000000 t .text0000000c T __addsf30000000c T __aeabi_fadd00000000 T __aeabi_frsub00000008 T __aeabi_fsub000001a4 T __aeabi_i2f000001d4 T __aeabi_l2f0000019c T __aeabi_ui2f000001c4 T __aeabi_ul2f000001d4 T __floatdisf000001a4 T __floatsisf000001c4 T __floatundisf0000019c T __floatunsisf00000008 T __subsf3
$ armv7a-hardfloat-linux-gnueabi-nm -a _arm_addsubsf3.o 00000000 n .ARM.attributes
00000000 b .bss
00000000 d .data
00000000 N .debug_abbrev
00000000 N .debug_aranges
00000000 N .debug_info
00000000 N .debug_line
00000000 n .note.GNU-stack
00000000 t .text
0000000c T __addsf3
0000000c T __aeabi_fadd
00000000 T __aeabi_frsub
00000008 T __aeabi_fsub
000001a4 T __aeabi_i2f
000001d4 T __aeabi_l2f
0000019c T __aeabi_ui2f
000001c4 T __aeabi_ul2f
000001d4 T __floatdisf
000001a4 T __floatsisf
000001c4 T __floatundisf
0000019c T __floatunsisf
00000008 T __subsf3
The disassembly of __aeabi_l2f returned :
$ LANG=C armv7a-hardfloat-linux-gnueabi-objdump -d _arm_addsubsf3.o _arm_addsubsf3.o: file format elf32-littlearmDisassembly of section .text:...000001d4 <__aeabi_l2f>: 1d4: e1902001 orrs r2, r0, r1 1d8: 012fff1e bxeq lr 1dc: e2113102 ands r3, r1, #-2147483648 ; 0x80000000 1e0: 5a000001 bpl 1ec <__aeabi_l2f+0x18> 1e4: e2700000 rsbs r0, r0, #0 1e8: e2e11000 rsc r1, r1, #0 1ec: e1b0c001 movs ip, r1 1f0: 01a0c000 moveq ip, r0 1f4: 01a01000 moveq r1, r0 1f8: 03a00000 moveq r0, #0 1fc: e383345b orr r3, r3, #1526726656 ; 0x5b000000 200: 02433201 subeq r3, r3, #268435456 ; 0x10000000 204: e2433502 sub r3, r3, #8388608 ; 0x800000 208: e16f2f1c clz r2, ip 20c: e2522008 subs r2, r2, #8 210: e0433b82 sub r3, r3, r2, lsl #23 214: ba000006 blt 234 <__aeabi_l2f+0x60> 218: e0833211 add r3, r3, r1, lsl r2 21c: e1a0c210 lsl ip, r0, r2 220: e2622020 rsb r2, r2, #32 224: e35c0102 cmp ip, #-2147483648 ; 0x80000000 228: e0a30230 adc r0, r3, r0, lsr r2 22c: 03c00001 biceq r0, r0, #1 230: e12fff1e bx lr 234: e2822020 add r2, r2, #32 238: e1a0c211 lsl ip, r1, r2 23c: e2622020 rsb r2, r2, #32 240: e190008c orrs r0, r0, ip, lsl #1 244: e0a30231 adc r0, r3, r1, lsr r2 248: 01c00fac biceq r0, r0, ip, lsr #31 24c: e12fff1e bx lr
$ LANG=C armv7a-hardfloat-linux-gnueabi-objdump -d _arm_addsubsf3.o
_arm_addsubsf3.o: file format elf32-littlearm
Disassembly of section .text:
000001d4 <__aeabi_l2f>:
1d4: e1902001 orrs r2, r0, r1
1d8: 012fff1e bxeq lr
1dc: e2113102 ands r3, r1, #-2147483648 ; 0x80000000
1e0: 5a000001 bpl 1ec <__aeabi_l2f+0x18>
1e4: e2700000 rsbs r0, r0, #0
1e8: e2e11000 rsc r1, r1, #0
1ec: e1b0c001 movs ip, r1
1f0: 01a0c000 moveq ip, r0
1f4: 01a01000 moveq r1, r0
1f8: 03a00000 moveq r0, #0
1fc: e383345b orr r3, r3, #1526726656 ; 0x5b000000
200: 02433201 subeq r3, r3, #268435456 ; 0x10000000
204: e2433502 sub r3, r3, #8388608 ; 0x800000
208: e16f2f1c clz r2, ip
20c: e2522008 subs r2, r2, #8
210: e0433b82 sub r3, r3, r2, lsl #23
214: ba000006 blt 234 <__aeabi_l2f+0x60>
218: e0833211 add r3, r3, r1, lsl r2
21c: e1a0c210 lsl ip, r0, r2
220: e2622020 rsb r2, r2, #32
224: e35c0102 cmp ip, #-2147483648 ; 0x80000000
228: e0a30230 adc r0, r3, r0, lsr r2
22c: 03c00001 biceq r0, r0, #1
230: e12fff1e bx lr
234: e2822020 add r2, r2, #32
238: e1a0c211 lsl ip, r1, r2
23c: e2622020 rsb r2, r2, #32
240: e190008c orrs r0, r0, ip, lsl #1
244: e0a30231 adc r0, r3, r1, lsr r2
248: 01c00fac biceq r0, r0, ip, lsr #31
24c: e12fff1e bx lr
This libgcc.a was generated during the compilation of GCC by crossdev, on a Gentoo system.
Hi bwasim,
as myy says, the file which would be linked from libgcc.a is not _floatdisf.o nor _arm_floatdisf.o, but _arm_addsubsf3.o is linked.
The __aeabi_l2f is defined in the _arm_addsubsf3.o.To know which library files had been linked is to compile a source file with "-Wl,-Map=output.map" option.
Best regards,Yasuhiko Koumoto.