Re: ld-linux and ld-funcs thoughts

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: ld-linux and ld-funcs thoughts

sfora dim
Hello.

I was expecting that ld-linux (from glibc) and ld (from binutils)
will have similarities. Albeit they are in two different packages
and developers, they both do some kind of linking and mess
with ELF (I'm talking Linux) files.

I was especially expecting ld-linux to use the BFD library, too.

But when I read the ld-linux sources (elf/rtld.c, dl*.c and friends)
I found out that ld-linux and the dl functions does not use the BFD.
They handle the ELF files directly. open, read, direct low-level
backend-style (in BFD terminology..) work.

Why is that ?

How come there are no linking-code similarities between ld and ld-linux ?

 Why does ld-linux and ld-funcs have to implement everything
again and not use the BFD library (or maybe a trimmed version
of it, so we won't waste memory and time on unwanted file formats) ?

why do everything from scratch ?  just for efficiency sake ?


Thanks
Sfora.
Reply | Threaded
Open this post in threaded view
|

ld-linux and ld-funcs thoughts

sfora dim
(had some sending problems, sorry for duplication if happened)

Hello.

I was expecting that ld-linux (from glibc) and ld (from binutils)
will have similarities. Albeit they are in two different packages
and developers, they both do some kind of linking and mess
with ELF (I'm talking Linux) files.

I was especially expecting ld-linux to use the BFD library, too.

But when I read the ld-linux sources (elf/rtld.c, dl*.c and friends)
I found out that ld-linux and the dl functions does not use the BFD.
They handle the ELF files directly. open, read, direct low-level
backend-style (in BFD terminology..) work.

Why is that ?

How come there are no linking-code similarities between ld and ld-linux ?

 Why does ld-linux and ld-funcs have to implement everything
again and not use the BFD library (or maybe a trimmed version
of it, so we won't waste memory and time on unwanted file formats) ?

why do everything from scratch ?  just for efficiency sake ?


Thanks
Sfora.
Reply | Threaded
Open this post in threaded view
|

Re: ld-linux and ld-funcs thoughts

Mike Frysinger
In reply to this post by sfora dim
On Tuesday 29 May 2007, sfora dim wrote:

> Hello.
>
> I was expecting that ld-linux (from glibc) and ld (from binutils)
> will have similarities. Albeit they are in two different packages
> and developers, they both do some kind of linking and mess
> with ELF (I'm talking Linux) files.
>
> I was especially expecting ld-linux to use the BFD library, too.
>
> But when I read the ld-linux sources (elf/rtld.c, dl*.c and friends)
> I found out that ld-linux and the dl functions does not use the BFD.
> They handle the ELF files directly. open, read, direct low-level
> backend-style (in BFD terminology..) work.
>
> Why is that ?
very very different goals ... glibc doesnt care about anything other than ELF

> How come there are no linking-code similarities between ld and ld-linux ?

ld from binutils for Linux ELF targets do exhibit the same behavior when it
comes to linking and library searching.  if you find a difference, e-mail the
binutils list

>  Why does ld-linux and ld-funcs have to implement everything
> again and not use the BFD library (or maybe a trimmed version
> of it, so we won't waste memory and time on unwanted file formats) ?
>
> why do everything from scratch ?  just for efficiency sake ?

isnt that enough ?
-mike

signature.asc (844 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ld-linux and ld-funcs thoughts

sfora dim
On 5/30/07, Mike Frysinger <[hidden email]> wrote:
> On Tuesday 29 May 2007, sfora dim wrote:
> >  Why does ld-linux and ld-funcs have to implement everything
> > again and not use the BFD library (or maybe a trimmed version
> > of it, so we won't waste memory and time on unwanted file formats) ?
> >
> > why do everything from scratch ?  just for efficiency sake ?
>
> isnt that enough ?

But doesn't that makes it hard for maintainance ? (every change or addition
have to be inflicted twice, both in binutils (in ld or in a BFD backend) and
in glibc (in elf/rtld.c or elf/ld*.c)) ?

thank you
sfora
> -mike
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ld-linux and ld-funcs thoughts

Mike Frysinger
On Wednesday 30 May 2007, sfora dim wrote:

> On 5/30/07, Mike Frysinger <[hidden email]> wrote:
> > On Tuesday 29 May 2007, sfora dim wrote:
> > >  Why does ld-linux and ld-funcs have to implement everything
> > > again and not use the BFD library (or maybe a trimmed version
> > > of it, so we won't waste memory and time on unwanted file formats) ?
> > >
> > > why do everything from scratch ?  just for efficiency sake ?
> >
> > isnt that enough ?
>
> But doesn't that makes it hard for maintainance ?
not really

> (every change or addition
> have to be inflicted twice, both in binutils (in ld or in a BFD backend)
> and in glibc (in elf/rtld.c or elf/ld*.c)) ?

the ELF spec isnt exactly fluid, it's a spec for a reason ... much of it is in
a finalized state.  any new features generally dont require large changes to
be supported in both places, plus the ldso merely needs to handle the ELF
things required for runtime while bfd needs to do a lot more.
-mike

signature.asc (844 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ld-linux and ld-funcs thoughts

sfora dim
thank you,
sfora
Reply | Threaded
Open this post in threaded view
|

Re: ld-linux and ld-funcs thoughts

Nick Alcock-2
In reply to this post by sfora dim
On 29 May 2007, sfora dim told this:
> why do everything from scratch ?  just for efficiency sake ?

That's not a `just'. Efficiency is *critical* for the dynamic linker,
because its overhead gets incurred on every exec() of a dynamically
linked program, far more often than the linker is run. (Robustness is
arguably more important, too.)

--
`On a scale of one to ten of usefulness, BBC BASIC was several points ahead
 of the competition, scoring a relatively respectable zero.' --- Peter Corlett