References to 'get_eit_entry' even with exceptions disabled

Asked by Liam Staskawicz

Hello!

Thanks for this toolchain. I've been building successfully with CodeSourcery tools, but would also like to be able to use the GCC ARM Embedded tools for comparison. However, I'm getting a link error that complains about some symbols related to exception handling that I do not want to include in my build.

A sample .cpp compilation looks like:

arm-none-eabi-gcc -c -Os -ffast-math -DVERSION=v0.9.2-123-g16de7ef -g3 -D__STDC_FORMAT_MACROS -Wall -Werror -Wno-unused -Wno-strict-aliasing -ffunction-sections -fdata-sections -fno-exceptions -fno-threadsafe-statics -fno-rtti -fno-use-cxa-atexit -mthumb -mcpu=cortex-m3 -mfix-cortex-m3-ldrd -msoft-float -mno-thumb-interwork -MD -MP -MF .dep/mysourcefile.stm32.o.d ../../firmware/master/stm32/mysourcefile.cpp -o ../../firmware/master/stm32/mysourcefile.stm32.o

And our link line looks like:

arm-none-eabi-gcc -o myapplication.elf ...all my .o files... -lm -Wl,--gc-sections -mthumb -mcpu=cortex-m3 -mfix-cortex-m3-ldrd -msoft-float -mno-thumb-interwork -Wl,-M -Wl,-Map=myapplication.map,--cref,--gc-sections,-u,IVT -T ../../firmware/myapplication/stm32/target.ld -nostartfiles

And the specific link errors I'm seeing:

/usr/local/Cellar/gcc-arm-none-eabi/4.6-2012q1/lib/gcc/arm-none-eabi/4.6.2/armv7-m/libgcc.a(unwind-arm.o): In function `get_eit_entry':
unwind-arm.c:(.text+0x144): undefined reference to `__exidx_start'
unwind-arm.c:(.text+0x148): undefined reference to `__exidx_end'
/usr/local/Cellar/gcc-arm-none-eabi/4.6-2012q1/lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-abort.o): In function `abort':
abort.c:(.text.abort+0xa): undefined reference to `_exit'
/usr/local/Cellar/gcc-arm-none-eabi/4.6-2012q1/lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-signalr.o): In function `_kill_r':
signalr.c:(.text._kill_r+0xe): undefined reference to `_kill'
/usr/local/Cellar/gcc-arm-none-eabi/4.6-2012q1/lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-signalr.o): In function `_getpid_r':
signalr.c:(.text._getpid_r+0x0): undefined reference to `_getpid'
collect2: ld returned 1 exit status

I haven't been able to find a detailed explanation of this, but have read that it might be related to compiling the toolchain with the flag --disable-newlib-supplied-syscalls.

I could of course stub these calls out, but would prefer to fix the issue in the correct spot, and not include unneeded code in my binaries.

Please let me know if I can provide any further info, and thanks again!

Liam

Question information

Language:
English Edit question
Status:
Answered
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Joey Ye (jinyun-ye) said :
#1

Liam,

Can you please send more information so that I can decide if it is related
to http://comments.gmane.org/gmane.comp.gcc.help/41025

1. Define dummy symbols for __exidx_start and __exidx_end some where
2. Add -lnosys to your linker command line. By now you should be able to
pass the link
3. Grep the map file to see if any of following object files are linked:
_divdi3 _moddi3 _udivdi3 _umoddi3 _udiv_w_sdiv _udivmoddi4

If answer of 3 is yes, then it is related to the problem linked aboved,
which is a known issue under fixing. If no, then need further dig to see
why your application tries to use unwinding function.

Thanks - Joey

On Wed, Jul 18, 2012 at 3:05 PM, Liam Staskawicz <
<email address hidden>> wrote:

> New question #203480 on GCC ARM Embedded:
> https://answers.launchpad.net/gcc-arm-embedded/+question/203480
>
> Hello!
>
> Thanks for this toolchain. I've been building successfully with
> CodeSourcery tools, but would also like to be able to use the GCC ARM
> Embedded tools for comparison. However, I'm getting a link error that
> complains about some symbols related to exception handling that I do not
> want to include in my build.
>
> A sample .cpp compilation looks like:
>
> arm-none-eabi-gcc -c -Os -ffast-math -DVERSION=v0.9.2-123-g16de7ef -g3
> -D__STDC_FORMAT_MACROS -Wall -Werror -Wno-unused -Wno-strict-aliasing
> -ffunction-sections -fdata-sections -fno-exceptions -fno-threadsafe-statics
> -fno-rtti -fno-use-cxa-atexit -mthumb -mcpu=cortex-m3 -mfix-cortex-m3-ldrd
> -msoft-float -mno-thumb-interwork -MD -MP -MF .dep/mysourcefile.stm32.o.d
> ../../firmware/master/stm32/mysourcefile.cpp -o
> ../../firmware/master/stm32/mysourcefile.stm32.o
>
> And our link line looks like:
>
> arm-none-eabi-gcc -o myapplication.elf ...all my .o files... -lm
> -Wl,--gc-sections -mthumb -mcpu=cortex-m3 -mfix-cortex-m3-ldrd -msoft-float
> -mno-thumb-interwork -Wl,-M
> -Wl,-Map=myapplication.map,--cref,--gc-sections,-u,IVT -T
> ../../firmware/myapplication/stm32/target.ld -nostartfiles
>
> And the specific link errors I'm seeing:
>
> /usr/local/Cellar/gcc-arm-none-eabi/4.6-2012q1/lib/gcc/arm-none-eabi/4.6.2/armv7-m/libgcc.a(unwind-arm.o):
> In function `get_eit_entry':
> unwind-arm.c:(.text+0x144): undefined reference to `__exidx_start'
> unwind-arm.c:(.text+0x148): undefined reference to `__exidx_end'
> /usr/local/Cellar/gcc-arm-none-eabi/4.6-2012q1/lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-abort.o):
> In function `abort':
> abort.c:(.text.abort+0xa): undefined reference to `_exit'
> /usr/local/Cellar/gcc-arm-none-eabi/4.6-2012q1/lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-signalr.o):
> In function `_kill_r':
> signalr.c:(.text._kill_r+0xe): undefined reference to `_kill'
> /usr/local/Cellar/gcc-arm-none-eabi/4.6-2012q1/lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-signalr.o):
> In function `_getpid_r':
> signalr.c:(.text._getpid_r+0x0): undefined reference to `_getpid'
> collect2: ld returned 1 exit status
>
> I haven't been able to find a detailed explanation of this, but have read
> that it might be related to compiling the toolchain with the flag
> --disable-newlib-supplied-syscalls.
>
> I could of course stub these calls out, but would prefer to fix the issue
> in the correct spot, and not include unneeded code in my binaries.
>
> Please let me know if I can provide any further info, and thanks again!
>
> Liam
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>

Revision history for this message
Liam Staskawicz (liamstask) said :
#2

Hi Joey,

Thanks for your response. I did steps 1 and 2 - the link step no longer complains about get_eit_entry , but it still fails for the other symbols:

arm-none-eabi-gcc -o myapplication.elf ...all my .o files.... -lm -Wl,--gc-sections -mthumb -mcpu=cortex-m3 -mfix-cortex-m3-ldrd -msoft-float -mno-thumb-interwork -Wl,-Map=master-stm32.map,--cref,--gc-sections,-u,IVT -T ../../firmware/master/stm32/target.ld -nostartfiles -lnosys
/usr/local/Cellar/gcc-arm-none-eabi/4.6-2012q1/lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-abort.o): In function `abort':
abort.c:(.text.abort+0xa): undefined reference to `_exit'
/usr/local/Cellar/gcc-arm-none-eabi/4.6-2012q1/lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-signalr.o): In function `_kill_r':
signalr.c:(.text._kill_r+0xe): undefined reference to `_kill'
/usr/local/Cellar/gcc-arm-none-eabi/4.6-2012q1/lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-signalr.o): In function `_getpid_r':
signalr.c:(.text._getpid_r+0x0): undefined reference to `_getpid'
collect2: ld returned 1 exit status

However, I did look through the generated map file and I do indeed see references to _divdi3 and _udivdi3, so it sounds like at least that part of the error is aligned with the known issue that you mentioned? Maybe the other failures are due to something else.

What do you think?

Thanks,
Liam

Revision history for this message
Joey Ye (jinyun-ye) said :
#3

Yes it is partly aligned to the known issue.

The remaining 3 missing symbols are in libnosys.a. You can reliably link
this lib by either
using -Wl,--start-group -lnosys -l_your_other_libs -Wl,--end-group in GCC
linker command line, or add following line to your linker script:
GROUP(libnosys.a, your_other_libs.a)

Thanks - Joey

On Fri, Jul 20, 2012 at 4:15 AM, Liam Staskawicz <
<email address hidden>> wrote:

> Question #203480 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/203480
>
> Status: Answered => Open
>
> Liam Staskawicz is still having a problem:
> Hi Joey,
>
> Thanks for your response. I did steps 1 and 2 - the link step no longer
> complains about get_eit_entry , but it still fails for the other
> symbols:
>
> arm-none-eabi-gcc -o myapplication.elf ...all my .o files.... -lm
> -Wl,--gc-sections -mthumb -mcpu=cortex-m3 -mfix-cortex-m3-ldrd -msoft-float
> -mno-thumb-interwork -Wl,-Map=master-stm32.map,--cref,--gc-sections,-u,IVT
> -T ../../firmware/master/stm32/target.ld -nostartfiles -lnosys
> /usr/local/Cellar/gcc-arm-none-eabi/4.6-2012q1/lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-abort.o):
> In function `abort':
> abort.c:(.text.abort+0xa): undefined reference to `_exit'
> /usr/local/Cellar/gcc-arm-none-eabi/4.6-2012q1/lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-signalr.o):
> In function `_kill_r':
> signalr.c:(.text._kill_r+0xe): undefined reference to `_kill'
> /usr/local/Cellar/gcc-arm-none-eabi/4.6-2012q1/lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib/armv7-m/libc.a(lib_a-signalr.o):
> In function `_getpid_r':
> signalr.c:(.text._getpid_r+0x0): undefined reference to `_getpid'
> collect2: ld returned 1 exit status
>
> However, I did look through the generated map file and I do indeed see
> references to _divdi3 and _udivdi3, so it sounds like at least that part
> of the error is aligned with the known issue that you mentioned? Maybe
> the other failures are due to something else.
>
> What do you think?
>
> Thanks,
> Liam
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>

Can you help with this problem?

Provide an answer of your own, or ask Liam Staskawicz for more information if necessary.

To post a message you must log in.