RE: Build a short executable

RE: Build a short executable

[David Korn]

>-----Original Message-----
>From: Pierre Saucourt-Harmel (r54698) 

>I removed the -g option to generate the cross libraries 
>(libg.a and libgcc.a) but not for my small files. I used -o2 
>everywhere and I obtained an executable file of 132656 bytes ! 

  Did you try using the 'strip' command from binutils on the output ? You'd
be surprised how much difference it might make.  It will be the main reason
why your exe is so large.

>With the generated map, I noticed more than 20 objects files 
>coming from libg.a and libgcc.a were *fully* loaded in my executable. 

  Yes, but each of those files is very small; by and large, each one
contains
just one or two functions, for this very reason: so that only the minimum
that
needs to be linked in will be.  Looking at your list, it's got things like
malloc and free, open, close, read and write; I assume your program wants to
use these functions ?

       DaveK
-- 
The Boulder Pledge: "Under no circumstances will I ever purchase anything 
offered to me as the result of an unsolicited email message. Nor will I 
forward chain letters, petitions, mass mailings, or virus warnings to large 
numbers of others. This is my contribution to the survival of the online
community."


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Build a short executable

[Peter Barada]

>>I removed the -g option to generate the cross libraries 
>>(libg.a and libgcc.a) but not for my small files. I used -o2 
>>everywhere and I obtained an executable file of 132656 bytes ! 
>
>  Did you try using the 'strip' command from binutils on the output ? You'd
>be surprised how much difference it might make.  It will be the main reason
>why your exe is so large.
>

Instead of strip, look at it with 'objdump --section-headers'
<foo.elf>.  This will tell you the size of each of the sections in the
executable(and where they are loaded) without losing any of the
symbols from the executable.

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Build a short executable

[Pierre Saucourt-Harmel (r54698)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3247 bytes --]

"Peter Barada (r1aaaa)" wrote:
Instead of strip, look at it with 'objdump --section-headers'
<foo.elf>.  This will tell you the size of each of the sections
in the
executable(and where they are loaded) without losing any of the
symbols from the executable.
 
Thanks.
I have tried "the strip" : I obtained an executables file of more than
110000 bytes.
But the "objdump --section-headers" gave me :
Sections:
Idx Name         
Size      VMA      
LMA       File off  Algn
  0 .textrom      00000060 
00000000  00000000  00008000  2**2
                 
CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data        
0000087c  00100000  00100000  00010000  2**2
                 
CONTENTS, ALLOC, LOAD, DATA
  2 .ctors        00000004 
0010087c  0010087c  0001087c  2**2
                 
CONTENTS, ALLOC, LOAD, DATA
  3 .dtors        00000004 
00100880  00100880  00010880  2**2
                 
CONTENTS, ALLOC, LOAD, DATA
  4 .bss         
00000184  00100884  00100884  00010884  2**2
                 
ALLOC
  5 .text        
00002c14  07800000  07800000  00018000  2**2
                 
CONTENTS, ALLOC, LOAD, READONLY, CODE
If I add all the section sizes, I obtain 0x367c = 13948 bytes.
But the total size of the executable file is explained by the file offset
which is increased of 0x8000 = 32 Kbytes each time the section is put in
a new memory region  (I have three memory regions defined in my linker
script : 1 rom and two separated ram.
I do not understand what is the interest to align the file offsets
(for different memory regions) to such segment size for a cross executable
file. I searched a linker option/command to control this file alignment
and I found only the PHDRS script command that allows to set the "program
headers" (or "segments") of the ELF object file format.
The "objdump -p" gave me the following "program headers" :
Program Header:
    LOAD off    0x00008000 vaddr
0x00000000 paddr 0x00000000 align 2**15
         filesz 0x00000060
memsz 0x00000060 flags r-x
    LOAD off    0x00010000 vaddr
0x00100000 paddr 0x00100000 align 2**15
         filesz 0x00000884
memsz 0x00000a08 flags rw-
    LOAD off    0x00018000 vaddr
0x07800000 paddr 0x07800000 align 2**15
         filesz 0x00002c14
memsz 0x00002c14 flags r-x
private flags = 0: [interworking not enabled] [APCS-32] [floats
passed in integer registers] [absolute position]
Does any know if I can put all my sections in the same program header
? How can I start this program header to the minimal value ?
 

Re: Build a short executable

[Pierre Saucourt-Harmel (r54698)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2139 bytes --]

"Pierre Saucourt-Harmel (r54698)" wrote:
[ .... ]
The "objdump -p" gave me the following "program headers" :
Program Header:
    LOAD off    0x00008000 vaddr
0x00000000 paddr 0x00000000 align 2**15
         filesz 0x00000060
memsz 0x00000060 flags r-x
    LOAD off    0x00010000 vaddr
0x00100000 paddr 0x00100000 align 2**15
         filesz 0x00000884
memsz 0x00000a08 flags rw-
    LOAD off    0x00018000 vaddr
0x07800000 paddr 0x07800000 align 2**15
         filesz 0x00002c14
memsz 0x00002c14 flags r-x
private flags = 0: [interworking not enabled] [APCS-32] [floats
passed in integer registers] [absolute position]
Does any know if I can put all my sections in the same program header
? How can I start this program header to the minimal value ?
 
I found how to avoid the page-alignment, reducing the LOAD offset of each
program header to the minimum. The --nmagic (the -n option does not seem
to work) of the linker turns off the page-alignment. The ld.document about
this option says:
-------------clip---------------------------------
`-n'
`--nmagic'
     Turn off page alignment of sections, and
mark the output as
     `NMAGIC' if possible.
-------------clip---------------------------------
And now I obtain:
Program Header:
    LOAD off    0x00000094 vaddr
0x00000000 paddr 0x00000000 align 2**2
         filesz 0x00000060
memsz 0x00000060 flags r-x
    LOAD off    0x000000f4 vaddr
0x00100000 paddr 0x00100000 align 2**2
         filesz 0x00000884
memsz 0x00000a08 flags rw-
    LOAD off    0x00000978 vaddr
0x07800000 paddr 0x07800000 align 2**2
         filesz 0x00002c14
memsz 0x00002c14 flags r-x
private flags = 0: [interworking not enabled] [APCS-32] [floats
passed in integer registers] [absolute position]
And my executable file contains now 14288 bytes against 110168 bytes
(stripping all symbols for both generations) !!
Pierre.
 

Re: Build a short executable

[Pierre Saucourt-Harmel (r54698)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2139 bytes --]

"Pierre Saucourt-Harmel (r54698)" wrote:
[ .... ]
The "objdump -p" gave me the following "program headers" :
Program Header:
    LOAD off    0x00008000 vaddr
0x00000000 paddr 0x00000000 align 2**15
         filesz 0x00000060
memsz 0x00000060 flags r-x
    LOAD off    0x00010000 vaddr
0x00100000 paddr 0x00100000 align 2**15
         filesz 0x00000884
memsz 0x00000a08 flags rw-
    LOAD off    0x00018000 vaddr
0x07800000 paddr 0x07800000 align 2**15
         filesz 0x00002c14
memsz 0x00002c14 flags r-x
private flags = 0: [interworking not enabled] [APCS-32] [floats
passed in integer registers] [absolute position]
Does any know if I can put all my sections in the same program header
? How can I start this program header to the minimal value ?
 
I found how to avoid the page-alignment, reducing the LOAD offset of each
program header to the minimum. The --nmagic (the -n option does not seem
to work) of the linker turns off the page-alignment. The ld.document about
this option says:
-------------clip---------------------------------
`-n'
`--nmagic'
     Turn off page alignment of sections, and
mark the output as
     `NMAGIC' if possible.
-------------clip---------------------------------
And now I obtain:
Program Header:
    LOAD off    0x00000094 vaddr
0x00000000 paddr 0x00000000 align 2**2
         filesz 0x00000060
memsz 0x00000060 flags r-x
    LOAD off    0x000000f4 vaddr
0x00100000 paddr 0x00100000 align 2**2
         filesz 0x00000884
memsz 0x00000a08 flags rw-
    LOAD off    0x00000978 vaddr
0x07800000 paddr 0x07800000 align 2**2
         filesz 0x00002c14
memsz 0x00002c14 flags r-x
private flags = 0: [interworking not enabled] [APCS-32] [floats
passed in integer registers] [absolute position]
And my executable file contains now 14288 bytes against 110168 bytes
(stripping all symbols for both generations) !!
Pierre.
 

Re: Build a short executable

[Pierre Saucourt-Harmel (r54698)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3247 bytes --]

"Peter Barada (r1aaaa)" wrote:
Instead of strip, look at it with 'objdump --section-headers'
<foo.elf>.  This will tell you the size of each of the sections
in the
executable(and where they are loaded) without losing any of the
symbols from the executable.
 
Thanks.
I have tried "the strip" : I obtained an executables file of more than
110000 bytes.
But the "objdump --section-headers" gave me :
Sections:
Idx Name         
Size      VMA      
LMA       File off  Algn
  0 .textrom      00000060 
00000000  00000000  00008000  2**2
                 
CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data        
0000087c  00100000  00100000  00010000  2**2
                 
CONTENTS, ALLOC, LOAD, DATA
  2 .ctors        00000004 
0010087c  0010087c  0001087c  2**2
                 
CONTENTS, ALLOC, LOAD, DATA
  3 .dtors        00000004 
00100880  00100880  00010880  2**2
                 
CONTENTS, ALLOC, LOAD, DATA
  4 .bss         
00000184  00100884  00100884  00010884  2**2
                 
ALLOC
  5 .text        
00002c14  07800000  07800000  00018000  2**2
                 
CONTENTS, ALLOC, LOAD, READONLY, CODE
If I add all the section sizes, I obtain 0x367c = 13948 bytes.
But the total size of the executable file is explained by the file offset
which is increased of 0x8000 = 32 Kbytes each time the section is put in
a new memory region  (I have three memory regions defined in my linker
script : 1 rom and two separated ram.
I do not understand what is the interest to align the file offsets
(for different memory regions) to such segment size for a cross executable
file. I searched a linker option/command to control this file alignment
and I found only the PHDRS script command that allows to set the "program
headers" (or "segments") of the ELF object file format.
The "objdump -p" gave me the following "program headers" :
Program Header:
    LOAD off    0x00008000 vaddr
0x00000000 paddr 0x00000000 align 2**15
         filesz 0x00000060
memsz 0x00000060 flags r-x
    LOAD off    0x00010000 vaddr
0x00100000 paddr 0x00100000 align 2**15
         filesz 0x00000884
memsz 0x00000a08 flags rw-
    LOAD off    0x00018000 vaddr
0x07800000 paddr 0x07800000 align 2**15
         filesz 0x00002c14
memsz 0x00002c14 flags r-x
private flags = 0: [interworking not enabled] [APCS-32] [floats
passed in integer registers] [absolute position]
Does any know if I can put all my sections in the same program header
? How can I start this program header to the minimal value ?
 

Re: Build a short executable

[Peter Barada]

>>I removed the -g option to generate the cross libraries 
>>(libg.a and libgcc.a) but not for my small files. I used -o2 
>>everywhere and I obtained an executable file of 132656 bytes ! 
>
>  Did you try using the 'strip' command from binutils on the output ? You'd
>be surprised how much difference it might make.  It will be the main reason
>why your exe is so large.
>

Instead of strip, look at it with 'objdump --section-headers'
<foo.elf>.  This will tell you the size of each of the sections in the
executable(and where they are loaded) without losing any of the
symbols from the executable.

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: Build a short executable

[David Korn]

>-----Original Message-----
>From: Pierre Saucourt-Harmel (r54698) 

>I removed the -g option to generate the cross libraries 
>(libg.a and libgcc.a) but not for my small files. I used -o2 
>everywhere and I obtained an executable file of 132656 bytes ! 

  Did you try using the 'strip' command from binutils on the output ? You'd
be surprised how much difference it might make.  It will be the main reason
why your exe is so large.

>With the generated map, I noticed more than 20 objects files 
>coming from libg.a and libgcc.a were *fully* loaded in my executable. 

  Yes, but each of those files is very small; by and large, each one
contains
just one or two functions, for this very reason: so that only the minimum
that
needs to be linked in will be.  Looking at your list, it's got things like
malloc and free, open, close, read and write; I assume your program wants to
use these functions ?

       DaveK
-- 
The Boulder Pledge: "Under no circumstances will I ever purchase anything 
offered to me as the result of an unsolicited email message. Nor will I 
forward chain letters, petitions, mass mailings, or virus warnings to large 
numbers of others. This is my contribution to the survival of the online
community."


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Build a short executable

[Pierre Saucourt-Harmel (r54698)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6879 bytes --]

Hello everybody,
I am trying to build a short program for a stand-alone ARM 7 processor
(without any OS), from a Solaris work station.
I generated sucessfully binutils-2.10.1, gcc-2.95.2, newlib-1.8.2 and
gdb-5.0.
I made a crt0.S (but refered to the default crtbegin.o). All my files
(*.c and crt0.S) explicitely call the external memset () and strlen ()
functions.
I removed the -g option to generate the cross libraries (libg.a and
libgcc.a) but not for my small files. I used -o2 everywhere and I obtained
an executable file of 132656 bytes !
With the generated map, I noticed more than 20 objects files coming
from libg.a and libgcc.a were *fully* loaded in my executable.
The linker processing that makes the symbol dependencies of the object
files (coming from libg.a and libgcc.a libraries) does not focus on which
function is used and which is not. The function dependencies and loading
seem to stop at the object level but not at the function level.
Is it possible to load what is strictly necessary ?
Here you find the archive includes, coming from the generated map :
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(__main.o)
                              
example.o (__gccmain)
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(_ctors.o)
                             
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(__main.o) (__CTOR_LIST__)
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(_exit.o)
                             
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(__main.o) (_exit_dummy_decl)
/lavalette/gnuInstall/arm-elf/lib/libg.a(atexit.o)
                             
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(__main.o) (atexit)
/lavalette/gnuInstall/arm-elf/lib/libg.a(impure.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(atexit.o) (_impure_ptr)
/lavalette/gnuInstall/arm-elf/lib/libg.a(malloc.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(atexit.o) (malloc)
/lavalette/gnuInstall/arm-elf/lib/libg.a(mallocr.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(malloc.o) (_malloc_r)
/lavalette/gnuInstall/arm-elf/lib/libg.a(memset.o)
                             
crt0.o (memset)
/lavalette/gnuInstall/arm-elf/lib/libg.a(mlock.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(mallocr.o) (__malloc_lock)
/lavalette/gnuInstall/arm-elf/lib/libg.a(sbrkr.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(mallocr.o) (_sbrk_r)
/lavalette/gnuInstall/arm-elf/lib/libg.a(strlen.o)
                             
example.o (strlen)
/lavalette/gnuInstall/arm-elf/lib/libg.a(syscalls.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(sbrkr.o) (_sbrk)
/lavalette/gnuInstall/arm-elf/lib/libg.a(errno.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(syscalls.o) (__errno)
/lavalette/gnuInstall/arm-elf/lib/libg.a(findfp.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(syscalls.o) (__sinit)
/lavalette/gnuInstall/arm-elf/lib/libg.a(freer.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(malloc.o) (_free_r)
/lavalette/gnuInstall/arm-elf/lib/libg.a(fwalk.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(findfp.o) (_fwalk)
/lavalette/gnuInstall/arm-elf/lib/libg.a(libcfunc.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(syscalls.o) (abort)
/lavalette/gnuInstall/arm-elf/lib/libg.a(stdio.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(findfp.o) (__sread)
/lavalette/gnuInstall/arm-elf/lib/libg.a(writer.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(stdio.o) (_write_r)
/lavalette/gnuInstall/arm-elf/lib/libg.a(closer.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(stdio.o) (_close_r)
/lavalette/gnuInstall/arm-elf/lib/libg.a(fflush.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(findfp.o) (fflush)
/lavalette/gnuInstall/arm-elf/lib/libg.a(lseekr.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(stdio.o) (_lseek_r)
/lavalette/gnuInstall/arm-elf/lib/libg.a(readr.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(stdio.o) (_read_r)
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(_udivsi3.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(freer.o) (__udivsi3)
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(_dvmd_tls.o)
                             
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(_udivsi3.o) (__div0)
 
 
 

Build a short executable

[Pierre Saucourt-Harmel (r54698)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6879 bytes --]

Hello everybody,
I am trying to build a short program for a stand-alone ARM 7 processor
(without any OS), from a Solaris work station.
I generated sucessfully binutils-2.10.1, gcc-2.95.2, newlib-1.8.2 and
gdb-5.0.
I made a crt0.S (but refered to the default crtbegin.o). All my files
(*.c and crt0.S) explicitely call the external memset () and strlen ()
functions.
I removed the -g option to generate the cross libraries (libg.a and
libgcc.a) but not for my small files. I used -o2 everywhere and I obtained
an executable file of 132656 bytes !
With the generated map, I noticed more than 20 objects files coming
from libg.a and libgcc.a were *fully* loaded in my executable.
The linker processing that makes the symbol dependencies of the object
files (coming from libg.a and libgcc.a libraries) does not focus on which
function is used and which is not. The function dependencies and loading
seem to stop at the object level but not at the function level.
Is it possible to load what is strictly necessary ?
Here you find the archive includes, coming from the generated map :
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(__main.o)
                              
example.o (__gccmain)
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(_ctors.o)
                             
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(__main.o) (__CTOR_LIST__)
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(_exit.o)
                             
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(__main.o) (_exit_dummy_decl)
/lavalette/gnuInstall/arm-elf/lib/libg.a(atexit.o)
                             
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(__main.o) (atexit)
/lavalette/gnuInstall/arm-elf/lib/libg.a(impure.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(atexit.o) (_impure_ptr)
/lavalette/gnuInstall/arm-elf/lib/libg.a(malloc.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(atexit.o) (malloc)
/lavalette/gnuInstall/arm-elf/lib/libg.a(mallocr.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(malloc.o) (_malloc_r)
/lavalette/gnuInstall/arm-elf/lib/libg.a(memset.o)
                             
crt0.o (memset)
/lavalette/gnuInstall/arm-elf/lib/libg.a(mlock.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(mallocr.o) (__malloc_lock)
/lavalette/gnuInstall/arm-elf/lib/libg.a(sbrkr.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(mallocr.o) (_sbrk_r)
/lavalette/gnuInstall/arm-elf/lib/libg.a(strlen.o)
                             
example.o (strlen)
/lavalette/gnuInstall/arm-elf/lib/libg.a(syscalls.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(sbrkr.o) (_sbrk)
/lavalette/gnuInstall/arm-elf/lib/libg.a(errno.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(syscalls.o) (__errno)
/lavalette/gnuInstall/arm-elf/lib/libg.a(findfp.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(syscalls.o) (__sinit)
/lavalette/gnuInstall/arm-elf/lib/libg.a(freer.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(malloc.o) (_free_r)
/lavalette/gnuInstall/arm-elf/lib/libg.a(fwalk.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(findfp.o) (_fwalk)
/lavalette/gnuInstall/arm-elf/lib/libg.a(libcfunc.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(syscalls.o) (abort)
/lavalette/gnuInstall/arm-elf/lib/libg.a(stdio.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(findfp.o) (__sread)
/lavalette/gnuInstall/arm-elf/lib/libg.a(writer.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(stdio.o) (_write_r)
/lavalette/gnuInstall/arm-elf/lib/libg.a(closer.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(stdio.o) (_close_r)
/lavalette/gnuInstall/arm-elf/lib/libg.a(fflush.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(findfp.o) (fflush)
/lavalette/gnuInstall/arm-elf/lib/libg.a(lseekr.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(stdio.o) (_lseek_r)
/lavalette/gnuInstall/arm-elf/lib/libg.a(readr.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(stdio.o) (_read_r)
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(_udivsi3.o)
                             
/lavalette/gnuInstall/arm-elf/lib/libg.a(freer.o) (__udivsi3)
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(_dvmd_tls.o)
                             
/lavalette/gnuInstall/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(_udivsi3.o) (__div0)