Linker ld

Similar Threads:

1.when is the dynamic linker ld.so called !!

> > Nope, there are no 'magically' loaded libraries. While libc.so is indeed
> > used by virtually every program it isn't mapped for the first time till
>  the
> > first program that uses it starts. As soon as no more processes have it
> > mmaped it will cease to 'consume' memory.
> 
>     Not only that, but it's not even loaded then. It's mapped, but it won't
> be loaded until the memory it was mapped into is accessed! This is known as
> 'faulting in'.
> 
This seems similar to DLLs in windows,but i thought that dl_* calls
were actually the equivalent of DLL's in Linux.Do you mean to say that
the actual mapping is done at runtime when we use dl_*
functions.Because as far as i know of dll's they are dynamically
loaded and unloaded when the last reference to it caeses to exist.The
unloading part is similar to unix shared libraries.Its the loading
part, and dl_* calls are actually close/equal to the dll's loading.

please correct me if iam wrong.
thanks
rohit

2.GNU linker ld usage question.

Hi..

Currently I've been looking into the Makefile of bootloader "DAS
U-Boot".
At final build stage, gnu linker links all object and produce
the u-boot by the following Makefile target rule:

u-boot:		depend $(SUBDIRS) $(OBJS) $(LIBS) $(LDSCRIPT)
		UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) | sed  -n -e
's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
		$(LD) $(LDFLAGS) $$UNDEF_SYM $(OBJS) \
			--start-group $(LIBS) $(PLATFORM_LIBS) --end-group \
			-Map u-boot.map -o u-boot

$(LDFLAGS) variable ends "-n" and UNDEF_SYM is undefined symbol name
list.
Can the undefined symbol names be the non-option argument of gnu ld?
According to manual page or info, I haven't found any mention of it.

Do I misunderstand at some point about usage of ld?
If anyone have a answer please let me know.

Thanks.

3.linker ld script

Hi
Can anyone help me with  Linker LD script memory allocation
I need to write a embedded bootloader

The bootloader should be placed i ROM at 0xa000 and above . The code should
include some function foo1()... foo10().  and main() and crt0

The CPU  starts at 0x0000 where it should be vector which should point to
crt0 (rom version)
.After boot process . The bootloader wil copy its Ram based program ( runing
in RAM) from external device (Rs232) .

The Memory is mapped as
000-0x50  Hardware vectors (prom)
0x52---0x1ffe  Program  RAM   Where the sshould be copied from external
device
2000-3000 Ram ( ram , heap , stack)
0xa000-0xc000 ROM (bootloader)

How should I  write a LD script file  for both Rom and Ram based version

With regards
George Arndt

4.Debian Etch - the LD Linker command

The LD command is part of the GNU binutils package,  Debian etch 
currently has version 2.17 in there package feed although version 2.18 
is available from GNU).

The LD program is the GNU linker program and has been around for some 
time.

I have noticed something very strange when checking through a log file 
generated while building a program.   The relevant log output is :-

checking for ld --version-script... no
*** WARNING: You should not compile GNU libc without versioning. Not 
using
*** versioning will introduce incompatibilities so that old binaries
*** will not run anymore.

But if I type ld -help it displays

   --version-script FILE       Read version information script

so it looks as if the --version-script option is supported because it is 
displayed as part of the help screen.


If I type 'ld --version-script' I get the following console output

ld: unrecognized option '--version-script' which infers that the 
--version-script option is not included.


Is this a possible bug,  perhaps either with the debian etch version or 
with the version compiled for any distro??
-- 
Robert Hammond   <Mailto: XXXX@XXXXX.COM >
PGP:0x154144DA

5.ld (linker) appears to set incorrect memory locations when plugin libraries involved

Hi everyone,

I'd be forever grateful (and quite impressed), if anyone knows the
solution to the following problem:

I have a program which links to many libraries (Qt, lapack, atlas, and
many more) and also loads plugin libraries via dlopen().


The plugin consists of only these functions:

void controller()
{
  cout << "got here" << endl;
}

void init(Object* x)
{
  void (**fn)() = &x->fn;
  *fn = controller;
  // these two statements equivalent to x->fn = controller and are
used for illustrate the problem
}


The program that loads the plugin (highly simplified and modified for
brevity):

int main()
{
  Object o;
  typedef void (*init_t)();

  // load init function
  void* handle = dlopen("plugin.so", DTLD_NOW);
  assert(handle);
  init_t init = (init_t) dlsym(handle, "init");
  const char *dlsym_error = dlerror();
  assert(!dlsym_error);
  (*init)(&o);

  // run controller
  if (o.controller)
    (*o.controller)();
  else
    cout << "no controller!" << endl;
}

Running this program yields the output "no controller!"

Debugging with gdb reveals that the statement void *(*fn) = &x->fn
uses the wrong memory address for x->fn (it is off by 0x70 bytes
according to gdb): the program is writing to the wrong location (I've
verified this).

I wouldn't mind including the source for my program, but it depends on
many libraries, at least one of which I can guarantee you don't have
installed.


Some clues:

If I link the code together with the program that loads and executes
the plugin (i.e., making it no longer a plugin), the code works
fine.

valgrind does not indicate any problems

I've tried RTLD_NOW, RTLD_GLOBAL, and RTLD_LAZY- makes no difference

In the past, I had weird problems occurring within my plugins (C++
RTTI would fail inexplicably when using data passed to the plugin),
but I was able to get around these problems and didn't spend the time
to diagnose the situation.

Source files are compiled with -fPIC

Problem occurs on 3 different unix machines (2 machines running
different distributions of linux and a OS X leopard machine).

I've tried building all third party libraries as shared libraries to
no effect.


Thanks for your help and your time,
Mantra

6. (relocating ld.so - possible?) ... a different ld.so

7. [PATCH v2 2/2] m68k: Cleanup linker scripts using new linker script macros.

8. "m68k: Cleanup linker scripts using new linker script macros." and old binutils (was: [PATCH] m68k: Atari EtherNAT - Nicolas Pitre has a new email address)