undefined reference to `__exidx_start' when starting new system,

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:

1

...

2

    .bss (NOLOAD) : {

3

        . = ALIGN(4);

4

        _szero = .;

5

        *(.bss)

6

        *(COMMON)

7

        . = ALIGN(4);

8

        _ezero = .;

9

    } >sram

10

11

12

    __exidx_start = .;

13

    .ARM.exidx   : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) } >sram

14

    __exidx_end = .;

15

...

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:

1

void abort(void)

2

{

3

  for (;;) { }

4

}

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

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

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.

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

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

Bloating:

1

   __exidx_start = .;

2

    .ARM.exidx   : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) } >sram

3

    __exidx_end = .;

4

  _etext = .;  /* define a global symbol _etext just after the last code byte */

Unbloating:

1

  .ARM.exidx : {

2

    __exidx_start = .;

3

     *(.ARM.exidx* .gnu.linkonce.armexidx.*) 

4

    __exidx_end = .;

5

  } >flash 

6

  _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)

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

Thanks for the update, Nils!