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