EmbDev.net

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


Author: Nils Soderman (nilswed)
Posted on:

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

Author: Jörg Wunsch (dl8dtl) (Moderator)
Posted on:

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 (;;) { }
}

Author: Nils Soderman (nilswed)
Posted on:

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

Author: Nils Soderman (nilswed)
Posted on:

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

Author: Jörg Wunsch (dl8dtl) (Moderator)
Posted on:

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.

Author: Nils Soderman (nilswed)
Posted on:

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

Author: Nils Soderman (nilswed)
Posted on:

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)

Author: Nils Soderman (nilswed)
Posted on:
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

Author: Jörg Wunsch (dl8dtl) (Moderator)
Posted on:

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.