EmbDev.net

Forum: ARM programming with GCC/GNU tools Super weird link behaviour


Author: Dan Quinz (danq)
Posted on:

Rate this post
0 useful
not useful
I have run into a particulary funny problem that perhaps someone else
has observed  and can comment/solve.

Given the following code segment:

----------
  test :
    {
      for (;;)
        {
          GPIO1_IOSET = 0x00010000 ;
          GPIO1_IOCLR = 0x00010000 ;
        }
    }
----------

The entire application compiles and executes correctly, generating a
square wave on the output pin.

When I comment out the 'for (;;)' statement, effectively reducing the
code to a single compound statement, the linker complains like hell that
it can't find a bunch of functions.  I am at a total loss as to why all
of a sudden these functions are needed.

Here is the edited code:

----------
  test :
    {
//    for (;;)
        {
          GPIO1_IOSET = 0x00010000 ;
          GPIO1_IOCLR = 0x00010000 ;
        }
    }
----------

Anyone got any idea of what is going on? Up until now, all my compiles
have been fine and no linker errors.  How is it possible a simple 'for
(;;)' statement omission can cause such linker behaviour?

Cheers!

Dan

Linker messages:

c:/winarm.20070505/bin/../lib/gcc/arm-elf/4.1.2/../../../../arm-elf/lib\ 
libc.a(lib_a-makebuf.o):
In function `__smakebuf_r':
makebuf.c:(.text+0x104): undefined reference to `isatty'
c:/winarm.20070505/bin/../lib/gcc/arm-elf/4.1.2/../../../../arm-elf/lib\ 
libnewlib-lpc.a(_close_r.o):
In function `_close_r':
C:\WinARM\utils\newlib_lpc_rel5a_src/_close_r.c:71: undefined reference
to `device_table'
c:/winarm.20070505/bin/../lib/gcc/arm-elf/4.1.2/../../../../arm-elf/lib\ 
libnewlib-lpc.a(_read_r.o):
In function `_read_r':
C:\WinARM\utils\newlib_lpc_rel5a_src/_read_r.c:84: undefined reference
to `device_table'
c:/winarm.20070505/bin/../lib/gcc/arm-elf/4.1.2/../../../../arm-elf/lib\ 
libnewlib-lpc.a(_write_r.o):
In function `_write_r':
C:\WinARM\utils\newlib_lpc_rel5a_src/_write_r.c:103: undefined reference
to `device_table'
c:/winarm.20070505/bin/../lib/gcc/arm-elf/4.1.2/../../../../arm-elf/lib\ 
libnewlib-lpc.a(_ioctl_r.o):
In function `_ioctl_r':
C:\WinARM\utils\newlib_lpc_rel5a_src/_ioctl_r.c:75: undefined reference
to `device_table'
collect2: ld returned 1 exit status

Author: Dan Quinz (danq)
Posted on:

Rate this post
0 useful
not useful
Some additional info:

Examining a listing of the build shows that not only is the stdio code
being included in the binary, but string functions (strcpy,etc.) and
memset.

It is as if changing the code slightly causes either the compiler or
linker to somehow include or not-include references to these functions.

When the additional code is not linked (when it works), the binary is
only +2k.  When it links the extra code, the binary goes to +47K.
Frustrating!

Since I do not make any references to any of these functions
(strcpy,memset,fopen,etc.), I cannot figure out why these are being
linked in.

Anybody got some clues as to what is going on?

Cheers!

Dan

Author: Dan Quinz (danq)
Posted on:

Rate this post
0 useful
not useful
Hi All,

I finally figured out what is happening with the code segment and the
external references:

When I was testing my code, I inserted this 'for (;;)' loop to do a
quick test.  The compiler recognized this as an infinite loop and
optimized out the following code.  Good compiler, good optimization.

As it turns out, the following code was some exception handling test
code "try/throw/catch", so by adding or removing the 'for (;;)' in the
test code, I was effectively removing/adding the exception handling test
code.

Finally, using exception handling requires the presence of a default
exception handler that is called when an unexpected exception is thrown.
The behavior of this function is defined and simple prints to 'stderr'
and terminates.  Hence the sudden external references.

When I remove all exception handling code and add the '-fno-exceptions'
option to the C++ compile, all external references to 'stdlib' code
disappear and the final test binary is a nice +2k in size instead of the
+47K I have be experiencing.

Now, if I remember correctly, there should be a way to override the
default unexpected exception handler so that I can point it to something
that does not use any IO. This would let me use exceptions without
incurring the huge code/ram penalty.

If anyone knows how to do that, please let me know.

Cheers!

Dan

PS: This also solves my earlier question(s) regarding a minimal compile.

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.