EmbDev.net

Forum: ARM programming with GCC/GNU tools undefined reference to `__exidx_start' when starting new system,


von Nils S. (nilswed)


Rate this post
0 useful
not useful
Hello, hope someone can give me a hint?
I have built a new system, now with Win7. I also upgraded to gcc 4.7.2.
When linking I get errors I never seen before:

make all
..linking
arm-none-eabi-ld -v -Map main.map -Tlinkconfig_FLASH.cmd -o main.out 
crt.o  main.o timerisr.o timersetup.o isrsupport.o lowlevelinit.o 
TWI_ctrl.o display.o HandleDDS.o menu.o buttons.o SPI_ctrl.o 
eepromhandler.o a2dmodule.o Smeter.o commands.o  cdc_enumerate.o 
serialARM.o  -L"C:/yagarto/lib/gcc/arm-none-eabi/4.7.2/" 
-L"C:/yagarto/arm-none-eabi/lib/" -lc -lgcc
GNU ld (GNU Binutils) 2.23.1
C:/yagarto/lib/gcc/arm-none-eabi/4.7.2/\libgcc.a(unwind-arm.o): In 
function `get_eit_entry':
C:\msys\1.0\home\yagarto\gcc-build\arm-none-eabi\libgcc/../../../gcc-4.7 
.2/libgcc/unwind-arm-common.inc:221:  undefined reference to 
`__exidx_start'
C:\msys\1.0\home\yagarto\gcc-build\arm-none-eabi\libgcc/../../../gcc-4.7 
.2/libgcc/unwind-arm-common.inc:221:  undefined reference to 
`__exidx_end'
C:/yagarto/lib/gcc/arm-none-eabi/4.7.2/\libgcc.a(unwind-arm.o): In 
function `unwind_phase2':
C:\msys\1.0\home\yagarto\gcc-build\arm-none-eabi\libgcc/../../../gcc-4.7 
.2/libgcc/unwind-arm-common.inc:289:  undefined reference to `abort'
C:/yagarto/lib/gcc/arm-none-eabi/4.7.2/\libgcc.a(unwind-arm.o): In 
function `__gnu_Unwind_Resume':
C:\msys\1.0\home\yagarto\gcc-build\arm-none-eabi\libgcc/../../../gcc-4.7 
.2/libgcc/unwind-arm-common.inc:487:  undefined reference to `abort'
C:\msys\1.0\home\yagarto\gcc-build\arm-none-eabi\libgcc/../../../gcc-4.7 
.2/libgcc/unwind-arm-common.inc:505:  undefined reference to `abort'
C:/yagarto/lib/gcc/arm-none-eabi/4.7.2/\libgcc.a(pr-support.o): In 
function `_Unwind_GetDataRelBase':
C:\msys\1.0\home\yagarto\gcc-build\arm-none-eabi\libgcc/../../../gcc-4.7 
.2/libgcc/config/arm/pr-support.c:394:  undefined reference to `abort'
C:/yagarto/lib/gcc/arm-none-eabi/4.7.2/\libgcc.a(pr-support.o): In 
function `_Unwind_GetTextRelBase':
C:\msys\1.0\home\yagarto\gcc-build\arm-none-eabi\libgcc/../../../gcc-4.7 
.2/libgcc/config/arm/pr-support.c:400:  undefined reference to `abort'
make: *** [main.out] Error 1

And I do not understand where "msys\1.0\home" in C:\msys\1.0\home\ etc 
come from...
I really would appreciate some hints...
Nils

von Jörg W. (dl8dtl) (Moderator)


Rate this post
0 useful
not useful
Answered by Ian Lance Taylor:

http://gcc.gnu.org/ml/gcc-help/2009-10/msg00335.html

"These and the other undefined symbols are intended to be defined by
the linker script."

For example:
...
    .bss (NOLOAD) : {
        . = ALIGN(4);
        _szero = .;
        *(.bss)
        *(COMMON)
        . = ALIGN(4);
        _ezero = .;
    } >sram


    __exidx_start = .;
    .ARM.exidx   : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) } >sram
    __exidx_end = .;
...

The function abort() is something you have to provide yourself.  Do
whatever seems to be most useful in case of a software-triggered
abort: flash some LEDs, beep a buzzer, whatever you've got.  The
most minimal abort function is certainly:
void abort(void)
{
  for (;;) { }
}

von Nils S. (nilswed)


Rate this post
0 useful
not useful
Thank you very much Ian!
Followed your suggestions and now I have a binary to load. Smoketest 
soon!
Please keep on helping us less developed!
Nils

von Nils S. (nilswed)


Rate this post
0 useful
not useful
Hi,
a small update!
I found out that the binary was 2MB+ big, a "tiny" bit too big for my 
flash (256KB)
So I made a small mod to your suggestion, Ian!

This is your version:

    __exidx_start = .;
    .ARM.exidx   : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) } >sram
    __exidx_end = .;

And after intensive study in another forum my version:

  .ARM.exidx : {
    __exidx_start = .;
     *(.ARM.exidx* .gnu.linkonce.armexidx.*)
    __exidx_end = .;
  } >flash
  _etext = .;  /* define a global symbol _etext just after the last code 
byte */

So now the binary is 94kB, more handy for the flash.

Don't ask ME why they give such different result!
Hope it will help somebody???
Nils

von Jörg W. (dl8dtl) (Moderator)


Rate this post
0 useful
not useful
Nils Soderman wrote:

> So I made a small mod to your suggestion, Ian!

Well, I am not Ian. ;-)  Ian Lance Taylor is a long-term opensource
contributor.

> This is your version:
>
>     __exidx_start = .;
>     .ARM.exidx   : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) } >sram
>     __exidx_end = .;
>
> And after intensive study in another forum my version:
>
>   .ARM.exidx : {
>     __exidx_start = .;
>      *(.ARM.exidx* .gnu.linkonce.armexidx.*)
>     __exidx_end = .;
>   } >flash

It would be interesting what did cause your bloat.  But thanks for
the feedback, I'll keep it in mind for my own stuff, too.

von Nils S. (nilswed)


Rate this post
0 useful
not useful
I am so sorry, Jörg!
Misunderstanding, me not reading the full answer! Sorry!
I missed:
>Answered by Ian Lance Taylor:

>http://gcc.gnu.org/ml/gcc-help/2009-10/msg00335.html

>"These and the other undefined symbols are intended to be defined by
>the linker script."

I will try to go back to the bloating version and look in the .map file, 
if possible. And get back to you with result.

Now time for BBC-news!
Bis morgen!
Nils

von Nils S. (nilswed)


Rate this post
0 useful
not useful
Hi Jörg (NOT Ian!!!)
Mapfiles show the sram pointer is at fault!

Bloating:
   __exidx_start = .;
    .ARM.exidx   : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) } >sram
    __exidx_end = .;
  _etext = .;  /* define a global symbol _etext just after the last code byte */

Unbloating:
  .ARM.exidx : {
    __exidx_start = .;
     *(.ARM.exidx* .gnu.linkonce.armexidx.*) 
    __exidx_end = .;
  } >flash 
  _etext = .;            /* define a global symbol _etext just after the last code byte */

So my QROlleII is now running nicely w/ new SW!
73 de Nils

(Moderator: deleted attachment to this post, see below)

von Nils S. (nilswed)


Attached files:

Rate this post
0 useful
not useful
Sorry, I have been bloating the forum: sent the bin file instead of the 
map files!!!

Hi Jörg (NOT Ian!!!)
Mapfiles show the sram pointer is at fault!

Bloating:

   __exidx_start = .;
    .ARM.exidx   : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) } >sram
    __exidx_end = .;
  _etext = .;  /* define a global symbol _etext just after the last code 
byte */


Unbloating:

  .ARM.exidx : {
    __exidx_start = .;
     *(.ARM.exidx* .gnu.linkonce.armexidx.*)
    __exidx_end = .;
  } >flash
  _etext = .;            /* define a global symbol _etext just after the 
last code byte */


So my QROlleII is now running nicely w/ new SW!
73 de Nils

von Jörg W. (dl8dtl) (Moderator)


Rate this post
0 useful
not useful
Thanks for the update, Nils!

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.