Referenced symbol not present in final image?

Referenced symbol not present in final image?

[Øyvind Harboe]

One more thing:

If I add -Wl,--undefined=pthread_mutex_lock, I get the expected result, 
i.e. that the pthread_mutex_lock fn is included in the final image.

$ arm-elf-gcc   -Wl,-static -g -nostdlib  -nostartfiles -L../romapp/install/lib -Ttarget.ld
  [truncated]  -Wl,-Map,output/rimi.map   -Wl,--trace-symbol=pthread_mutex_lock  -Wl,--undefined=pthread_mutex_lock
/ecos-c/cdtworkspace/arm/install/bin/../lib/gcc/arm-elf/3.4.3/../../../../arm-elf/lib/libsupc++.a(eh_alloc.o): reference to pthread_mutex_lock
/ecos-c/cdtworkspace/arm/install/bin/../lib/gcc/arm-elf/3.4.3/../../../../arm-elf/lib/libstdc++.a(locale_init.o): reference to pthread_mutex_lock
/ecos-c/cdtworkspace/arm/install/bin/../lib/gcc/arm-elf/3.4.3/../../../../arm-elf/lib/libstdc++.a(allocator-inst.o): reference to pthread_mutex_lock
../romapp/install/lib/libtarget.a(compat_posix_mutex.o): definition of pthread_mutex_lock



-- 
Øyvind Harboe
http://www.zylin.com

RE: Referenced symbol not present in final image?

[Dave Korn]

----Original Message----
>From: Øyvind Harboe
>Sent: 08 April 2005 12:15

> One more thing:
> 
> If I add -Wl,--undefined=pthread_mutex_lock, I get the expected result,
> i.e. that the pthread_mutex_lock fn is included in the final image.
> 
> $ arm-elf-gcc   -Wl,-static -g -nostdlib  -nostartfiles
>   -L../romapp/install/lib -Ttarget.ld [truncated] 
> -Wl,-Map,output/rimi.map   -Wl,--trace-symbol=pthread_mutex_lock 
> -Wl,--undefined=pthread_mutex_lock
>
/ecos-c/cdtworkspace/arm/install/bin/../lib/gcc/arm-elf/3.4.3/../../../../ar
m-elf/lib/libsupc++.a(eh_alloc.o):
> reference to pthread_mutex_lock
>
/ecos-c/cdtworkspace/arm/install/bin/../lib/gcc/arm-elf/3.4.3/../../../../ar
m-elf/lib/libstdc++.a(locale_init.o):
> reference to pthread_mutex_lock
>
/ecos-c/cdtworkspace/arm/install/bin/../lib/gcc/arm-elf/3.4.3/../../../../ar
m-elf/lib/libstdc++.a(allocator-inst.o):
> reference to pthread_mutex_lock
> ../romapp/install/lib/libtarget.a(compat_posix_mutex.o): definition of
> pthread_mutex_lock      


  Umm, look, if you really want to know what kind of symbol it is, don't you
just want to be using "nm" or "objdump --syms" on eh_alloc.o (or libsupc++),
and it'll probably tell you something interesting like it's weak, or common,
or somesuch ?

  If it's referenced, but doesn't get pulled into the link unless you -U it
on the linker command line, that suggests that the object that contains it
is too early in the link order and the objects that reference it are too
late in the link order, so by the time the linker knows it's needed, it's
already gone by and be discarded.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

RE: Referenced symbol not present in final image?

[Øyvind Harboe]

>   Umm, look, if you really want to know what kind of symbol it is, don't you
> just want to be using "nm" or "objdump --syms" on eh_alloc.o (or libsupc++),
> and it'll probably tell you something interesting like it's weak, or common,
> or somesuch ?
>
>   If it's referenced, but doesn't get pulled into the link unless you -U it
> on the linker command line, that suggests that the object that contains it
> is too early in the link order and the objects that reference it are too
> late in the link order, so by the time the linker knows it's needed, it's
> already gone by and be discarded.

The symbol in question is weak, which explains the "strange" behaviour. 

Thanks for the tip(s)!

--- a reply I got in mail directly -----


If you define a symbol as weak and do not provide a definition for the
same (as in the example below) then the linker would allow the symbol
to be undefined but still referenced in the binary.

<snip>

#include<stdio.h>

void foo() __attribute__ ((weak));

int main()
{
  int c;
  
  if(!c)
    foo();
  
  return 0;
}

</snip>

--- a reply I got in mail directly -----

-- 
Øyvind Harboe
http://www.zylin.com

Referenced symbol not present in final image?

[Øyvind Harboe]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

Using binutils 2.15:

Under what circumstances would the linker allow a symbol to be
referenced but not defined?

In the image, pthread_mutex_lock=0, so anyone trying to call
pthread_mutex_lock crashes when trying to access address 0.

When trying --trace-symbol, the symbol is referenced but never defined. 

$ arm-elf-gcc -Wl,-static -g [trimmed] -nostdlib  -nostartfiles
-L../romapp/install/lib -Ttarget.ld -trace-symbol=pthread_mutex_lock 
output/./main.o: reference to pthread_mutex_lock
/ecos-c/cdtworkspace/arm/install/bin/../lib/gcc/arm-elf/3.4.3/../../../../arm-elf/lib/libsupc++.a(eh_alloc.o): reference to pthread_mutex_lock
/ecos-c/cdtworkspace/arm/install/bin/../lib/gcc/arm-elf/3.4.3/../../../../arm-elf/lib/libstdc++.a(locale_init.o): reference to pthread_mutex_lock
/ecos-c/cdtworkspace/arm/install/bin/../lib/gcc/arm-elf/3.4.3/../../../../arm-elf/lib/libstdc++.a(allocator-inst.o): reference to pthread_mutex_lock



(My goal is to get libstdc++ w/gcc 3.4.3 working for
http://sources.redhat.com/ecos)



-- 
Øyvind Harboe
http://www.zylin.com




[-- Attachment #2: target.ld --]
[-- Type: text/plain, Size: 2281 bytes --]

STARTUP(vectors.o)
ENTRY(reset_vector)
INPUT(extras.o)

GROUP(libgcc.a libsupc++.a libstdc++.a libtarget.a)
MEMORY
{
    ram : ORIGIN = 0x00000000, LENGTH = 0x40000
    rom : ORIGIN = 0x01030000, LENGTH = 0x1d0000
}

SECTIONS
{
    .debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } .debug_info 0 : { *(.debug_info) } .debug_abbrev 0 : { *(.debug_abbrev) } .debug_line 0 : { *(.debug_line) } .debug_frame 0 : { *(.debug_frame) } .debug_str 0 : { *(.debug_str) } .debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0 : { *(.debug_macinfo) } .note.arm.ident 0 : { KEEP (*(.note.arm.ident)) }
    .rom_vectors 0x01030000 : { __rom_vectors_vma = ABSOLUTE(.); . = .; KEEP (*(.vectors)) } > rom __rom_vectors_lma = LOADADDR(.rom_vectors);
    .text ALIGN (0x1) : { _stext = ABSOLUTE(.); PROVIDE (__stext = ABSOLUTE(.)); *(.text*) *(.gnu.warning) *(.gnu.linkonce.t.*) *(.init) *(.glue_7) *(.glue_7t) } > rom _etext = .; PROVIDE (__etext = .);
    .fini ALIGN (0x4) : { . = .; *(.fini) } > rom
    .rodata ALIGN (0x4) : { . = .; *(.rodata*) *(.gnu.linkonce.r.*) } > rom
    .rodata1 ALIGN (0x4) : { . = .; *(.rodata1) } > rom
    .fixup ALIGN (0x4) : { . = .; *(.fixup) } > rom
    .gcc_except_table ALIGN (0x4) : { . = .; *(.gcc_except_table) } > rom
    .fixed_vectors 0x20 : { . = .; KEEP (*(.fixed_vectors)) } > ram
    .data 0x4000 : AT ((LOADADDR (.gcc_except_table) + SIZEOF (.gcc_except_table) + 4 - 1) & ~ (4 - 1)) { __ram_data_start = ABSOLUTE (.); *(.data*) *(.data1) *(.gnu.linkonce.d.*) . = ALIGN (4); KEEP(*( SORT (.ecos.table.*))) ; . = ALIGN (4); __CTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.ctors*))) __CTOR_END__ = ABSOLUTE (.); __DTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.dtors*))) __DTOR_END__ = ABSOLUTE (.); *(.dynamic) *(.sdata*) *(.gnu.linkonce.s.*) . = ALIGN (4); *(.2ram.*) } > ram __rom_data_start = LOADADDR (.data); __ram_data_end = .; PROVIDE (__ram_data_end = .); _edata = .; PROVIDE (edata = .); PROVIDE (__rom_data_end = LOADADDR (.data) + SIZEOF(.data));
    .bss ALIGN (0x4) : { __bss_start = ABSOLUTE (.); *(.scommon) *(.dynsbss) *(.sbss*) *(.gnu.linkonce.sb.*) *(.dynbss) *(.bss*) *(.gnu.linkonce.b.*) *(COMMON) __bss_end = ABSOLUTE (.); } > ram
    __heap1 = ALIGN (0x8);
    . = ALIGN(4); _end = .; PROVIDE (end = .);
}

Re: Referenced symbol not present in final image?

[Ravi Ramaseshan]

On Apr 8, 2005 4:00 PM, Øyvind Harboe <oyvind.harboe@zylin.com> wrote:
> Using binutils 2.15:
> 
> Under what circumstances would the linker allow a symbol to be
> referenced but not defined?

If you define a symbol as weak and do not provide a definition for the
same (as in the example below) then the linker would allow the symbol
to be undefined but still referenced in the binary.

<snip>

#include<stdio.h>

void foo() __attribute__ ((weak));

int main()
{
 int c;

 if(!c)
   foo();

 return 0;
}

</snip>

Regards,
Ravi Ramaseshan.

PS: Please correct me if I am wrong. Sorry for the incomplete reply I
sent earlier.

-- 
" All man's miseries derive from not being able to sit in a room alone. "
- Blaise Pascal