public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* Referenced symbol not present in final image?
@ 2005-04-08 10:30 Øyvind Harboe
  2005-04-08 12:23 ` Ravi Ramaseshan
  0 siblings, 1 reply; 5+ messages in thread
From: Øyvind Harboe @ 2005-04-08 10:30 UTC (permalink / raw)
  To: binutils

[-- 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 = .);
}

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Referenced symbol not present in final image?
  2005-04-08 10:30 Referenced symbol not present in final image? Øyvind Harboe
@ 2005-04-08 12:23 ` Ravi Ramaseshan
  0 siblings, 0 replies; 5+ messages in thread
From: Ravi Ramaseshan @ 2005-04-08 12:23 UTC (permalink / raw)
  To: Øyvind Harboe; +Cc: binutils

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Referenced symbol not present in final image?
  2005-04-08 12:17 ` Dave Korn
@ 2005-04-08 12:31   ` Øyvind Harboe
  0 siblings, 0 replies; 5+ messages in thread
From: Øyvind Harboe @ 2005-04-08 12:31 UTC (permalink / raw)
  To: Dave Korn; +Cc: binutils

>   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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Referenced symbol not present in final image?
  2005-04-08 11:14 Øyvind Harboe
@ 2005-04-08 12:17 ` Dave Korn
  2005-04-08 12:31   ` Øyvind Harboe
  0 siblings, 1 reply; 5+ messages in thread
From: Dave Korn @ 2005-04-08 12:17 UTC (permalink / raw)
  To: 'Øyvind Harboe', binutils

----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....

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Referenced symbol not present in final image?
@ 2005-04-08 11:14 Øyvind Harboe
  2005-04-08 12:17 ` Dave Korn
  0 siblings, 1 reply; 5+ messages in thread
From: Øyvind Harboe @ 2005-04-08 11:14 UTC (permalink / raw)
  To: binutils

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




^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2005-04-08 12:31 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-04-08 10:30 Referenced symbol not present in final image? Øyvind Harboe
2005-04-08 12:23 ` Ravi Ramaseshan
2005-04-08 11:14 Øyvind Harboe
2005-04-08 12:17 ` Dave Korn
2005-04-08 12:31   ` Øyvind Harboe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).