Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > How do linkers work?

Reply
Thread Tools

How do linkers work?

 
 
Kenny McCormack
Guest
Posts: n/a
 
      03-24-2008
In article <fs8fll$2ps5$(E-Mail Removed)>,
Richard Tobin <(E-Mail Removed)> wrote:
>In article <(E-Mail Removed)>,
>John Bode <(E-Mail Removed)> wrote something sensible, logical,
>and helpful, starting with:
>
>>Linkers are defined by the platform, not the language;

>
>No, by both.
>
>>there is no C-
>>specific linker (AFAIK), just like there is no C++-specific linker or
>>Fortran-specific linker or Pascal-specific linker (am I sufficiently
>>showing my age?). The same linker can be used for all of the above;

>
>Obviously a sufficiently complicated linker can be used for
>everything. But until quite recently most linkers that were adequate
>for C were *not* adequate for C++. Gcc's C++ for example had an
>associated program "collect2" that provided the linkage features
>absent in typical unix linkers (in particular, if I understand
>correctly, support for initialisation by C++ constructors).


And therefore, I fear deeply for his clique membership.
Downfall looks imminent.

 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      03-24-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
[snip]

Look, I just do not understand where you want to go

It is impossible to explain object files in a few words, i.e. in a
newsgroup posting, mentioning ALL possible forms an object file
can have.

That is why I explained the concept of separate compilation,
and the three parts that an object file must have, when separate
compilation is done.

Your example of the switch of MSVC doesn't apply here because actually
there is no separate compilation precisely. There is no linking and
there is no linker since all the inteermediate code is just
thrown into a back end.

I should have answered you that first.

Then, what it means "conceptually"

It means that I did not want to get very precise as to what is
actually in each of the formats of object files around because they
can change a lot.

That is why I insisted only in the general concepts of what must
be inside:
o Symbol Table
o Relocations
o Sections

And even if the object files vary a lot, there isn't
any object file (that supports separate compilation) that
doesn't have at least that inside.

Obviously, you feel an urge to polemic, irony etc.

Maybe because you have still not swallowed the fact that
the non existent stack is universally present

Now, you get into philosophy.

EPROMS are executables?

They have surely another format, but they do not have
an essential characteristic of executable files.

Executable files are files that are RELOCATABLE. They
can be loaded at different addresses in memory. Even if in
many systems that use virtual memory that address is fixed,
the shared objects (dlls) are truly relocatable.

Files in EPROM/ ROM are NOT relocatable therefore they are NOT
executable files in the normal sense.

They can be executed of course, but their organization is completely
different because there is no loader.

I will come back to executable formats when I describe the linker in
more detail.




--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
 
 
 
John Bode
Guest
Posts: n/a
 
      03-24-2008
On Mar 24, 3:29 pm, (E-Mail Removed) (Kenny McCormack)
wrote:
> In article <fs8fll$(E-Mail Removed)>,
>
>
>
> Richard Tobin <(E-Mail Removed)> wrote:
> >In article <(E-Mail Removed)>,
> >John Bode <(E-Mail Removed)> wrote something sensible, logical,
> >and helpful, starting with:

>
> >>Linkers are defined by the platform, not the language;

>
> >No, by both.

>
> >>there is no C-
> >>specific linker (AFAIK), just like there is no C++-specific linker or
> >>Fortran-specific linker or Pascal-specific linker (am I sufficiently
> >>showing my age?). The same linker can be used for all of the above;

>
> >Obviously a sufficiently complicated linker can be used for
> >everything. But until quite recently most linkers that were adequate
> >for C were *not* adequate for C++. Gcc's C++ for example had an
> >associated program "collect2" that provided the linkage features
> >absent in typical unix linkers (in particular, if I understand
> >correctly, support for initialisation by C++ constructors).

>
> And therefore, I fear deeply for his clique membership.
> Downfall looks imminent.


Breaking my own rule, but...

TINFC. GTFOY. HTH. HAND.
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      03-24-2008
jacob navia wrote, On 24/03/08 20:38:
> (E-Mail Removed) wrote:
> [snip]
>
> Look, I just do not understand where you want to go


He probably wants this to go to a group where it it is topical.

> It is impossible to explain object files in a few words, i.e. in a
> newsgroup posting, mentioning ALL possible forms an object file
> can have.


Which is why there are system specific groups and for more general stuff
more general groups.

> That is why I explained the concept of separate compilation,
> and the three parts that an object file must have, when separate
> compilation is done.


Ah, but it isn't always done and isn't topical here.

> Your example of the switch of MSVC doesn't apply here because actually
> there is no separate compilation precisely. There is no linking and
> there is no linker since all the inteermediate code is just
> thrown into a back end.


So, in other words, your post was specific to certain implementations
with certain combinations of switches. I.e. it is not generally correct.

> I should have answered you that first.
>
> Then, what it means "conceptually"
>
> It means that I did not want to get very precise as to what is
> actually in each of the formats of object files around because they
> can change a lot.
>
> That is why I insisted only in the general concepts of what must
> be inside:
> o Symbol Table
> o Relocations
> o Sections


Some code on some processors can be relocatable *without* relocation
tables. In fact, on some processors the code is smaller and faster if it
is relocatable! Then, of course, there are C interpreters which don't
have any of that.

<snip>

> I will come back to executable formats when I describe the linker in
> more detail.


Please don't. You have already demonstrated in this post that it is
highly implementation specific which *should* be enough for you to see
why it is not topical here.
--
Flash Gordon
 
Reply With Quote
 
robertwessel2@yahoo.com
Guest
Posts: n/a
 
      03-24-2008
On Mar 24, 3:38*pm, jacob navia <(E-Mail Removed)> wrote:
> (E-Mail Removed) wrote:
>
> [snip]
>
> Look, I just do not understand where you want to go
>
> It is impossible to explain object files in a few words, i.e. in a
> newsgroup posting, mentioning ALL possible forms an object file
> can have.
>
> That is why I explained the concept of separate compilation,
> and the three parts that an object file must have, when separate
> compilation is done.
>
> Your example of the switch of MSVC doesn't apply here because actually
> there is no separate compilation precisely. There is no linking and
> there is no linker since all the inteermediate code is just
> thrown into a back end.
>
> I should have answered you that first.



OK, I type:

cl -GL program1.c
cl -GL program2.c
link program1.obj+program2.obj

You're claiming that this is somehow *not* separate compilation as
normally understood? Even though the invocations of CL fully parse
and error check the input programs? And do who knows how much
analysis.

I'm sorry, but that's a really silly assertion. The implementation
details of what happens when and where in the process are just that:
implementation details. The fact the some part (*part*) of what's
traditionally considered the compilation process happens a bit latter
than usual, makes no difference.

And if I remove the -"GL" from the command lines, I get a program that
does exactly the same thing, just a little slower. Again, so what?
The fact that the vendor did something odd and funky under the hood
that allows the final program to run faster is not relevant to the
process.

And what would be your dividing line between what functions are
allowed in a linker before it becomes something other than a linker.
Plenty of linkers have done all sorts of things in the process of
generating executables. Plenty of linkers can patch up branches so
that a shorter form is used if the target is in range. Some linkers
can add overlay processing to a program. Some linkers can search for
missing code in libraries and conditionally add it to the executable.
Heck, what happens when code gets patched up at *runtime*? Is the
compiler now in the runtime somewhere?


> Then, what it means "conceptually"
>
> It means that I did not want to get very precise as to what is
> actually in each of the formats of object files around because they
> can change a lot.
>
> That is why I insisted only in the general concepts of what must
> be inside:
> o Symbol Table
> o Relocations
> o Sections
>
> And even if the object files vary a lot, there isn't
> any object file (that supports separate compilation) that
> doesn't have at least that inside.



While you might have such things internally in the linker in some
cases, are you really trying to argue that the transitory existence of
some internal structure is a fundamental part of C?


> Obviously, you feel an urge to polemic, irony etc.
>
> Maybe because you have still not swallowed the fact that
> the non existent stack is universally present



No. You've said "an object file has..." I think that's overbroad, to
be point of being an outright error. "Commonly, an object file
has..." would be rather more reasonable. You're trying to argue the
former, even when I've given you a simple example where it's not
correct.

In essence you're trying to apply the as-if rule to the behavior of
the compiler/linker system in regards to the stuff in the output from
a translation of a translation unit. That's reasonable, except that
you've got the wrong basis for your as-if. Program1 has a reference
of some type to program2. That has to be resolved in the linking
step, but it does *not* require the traditional object file structures
to do that.

As a practical example, most systems that support link-time code
generation do not actually produce anything, internal or external,
that looks like a traditional object file for each translation unit.
It simply never exists. Rather they *do* typically produce an object
file (often internally, or as a temporary file - same thing), but
*one* object file, that is the combination of all the programs tossed
into the back end. In fact the object file looks like what would
happen if you pasted the source code for all the programs together and
then compiled them as a unit. In practice, the common technique is to
past together the parse trees, after patching up some names so you
don't get collisions and the like.

That one object file is then typically run through the traditional
link process to deal with libraries and whatnot (and other objects
from different compilers).


> Now, you get into philosophy.
>
> EPROMS are executables?
>
> They have surely another format, but they do not have
> an essential characteristic of executable files.
>
> Executable files are files that are RELOCATABLE. They
> can be loaded at different addresses in memory. Even if in
> many systems that use virtual memory that address is fixed,
> the shared objects (dlls) are truly relocatable.
>
> Files in EPROM/ ROM are NOT relocatable therefore they are NOT
> executable files in the normal sense.
>
> They can be executed of course, but their organization is completely
> different because there is no loader.



Good god I must be old. I remember that relocating linkers were once
the option or *upgrade* from the "normal" form. Heck, once upon a
time we worried that the extra overhead from the relocated versions of
the executables cost too much. Relocation is *not* a characteristic
attribute of executable files.

But I'm confused. It sounds like *you're* arguing that executables
are not really required. Which doesn't sound like you...
 
Reply With Quote
 
Bartc
Guest
Posts: n/a
 
      03-25-2008
(E-Mail Removed) wrote:
> On Mar 23, 6:16 pm, jacob navia <(E-Mail Removed)> wrote:
>> What is important in the context of this discussion, is
>> what is inside from the language viewpoint.
>>
>> An object file contains:
>> o A symbol table of exported symbols
>> o Several "sections" of data.
>> o Relocation information

>
>
> You keep presenting this stuff as absolute, when it's not.


As I understand linking, it's resolving dependencies between separately
compiled modules before creating a runnable form of the program. That could
be done by any process at all, with intermediate files or not.

But *traditionally* it would be done the way Jacob has outlined.

So you're right, there are any number of ways of achieving the same ends.
But it doesn't mean you can't talk about a very common way of doing it.
Otherwise you wouldn't be able to talk about anything.

Whether c.l.c is an appropriate place for it is another matter. But I'm not
bothered about it myself.

--
Bart



 
Reply With Quote
 
user923005
Guest
Posts: n/a
 
      03-25-2008
On Mar 24, 5:23*pm, "Bartc" <(E-Mail Removed)> wrote:
> (E-Mail Removed) wrote:
> > On Mar 23, 6:16 pm, jacob navia <(E-Mail Removed)> wrote:
> >> What is important in the context of this discussion, is
> >> what is inside from the language viewpoint.

>
> >> An object file contains:
> >> o A symbol table of exported symbols
> >> o Several "sections" of data.
> >> o Relocation information

>
> > You keep presenting this stuff as absolute, when it's not.

>
> As I understand linking, it's resolving dependencies between separately
> compiled modules before creating a runnable form of the program. That could
> be done by any process at all, with intermediate files or not.
>
> But *traditionally* it would be done the way Jacob has outlined.
>
> So you're right, there are any number of ways of achieving the same ends.
> But it doesn't mean you can't talk about a very common way of doing it.
> Otherwise you wouldn't be able to talk about anything.
>
> Whether c.l.c is an appropriate place for it is another matter. But I'm not
> bothered about it myself.


Let's not forget GSMATCH:

LINK

GSMATCH

Sets match control parameters for a shareable image and
specifies
the match algorithm. This option allows you to control whether
executable images that link with a shareable image must be
relinked each time the shareable image is updated and relinked.

Format

GSMATCH=keyword,major-id,minor-id

GSMATCH=EQUAL,link-time-derived-major-id,link-time-derived-
minor-id
(default)




Additional information available:

Option_Values

 
Reply With Quote
 
user923005
Guest
Posts: n/a
 
      03-25-2008
On Mar 23, 4:16*pm, jacob navia <(E-Mail Removed)> wrote:
{snip}
Here is the same thing, more succintly and accurately:
http://en.wikipedia.org/wiki/Linker
I guess that anybody wants to program and who is smart enough to
become a programmer could find it in two seconds.

 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      03-25-2008
John Bode <(E-Mail Removed)> writes:

> On Mar 24, 3:29 pm, (E-Mail Removed) (Kenny McCormack)
> wrote:
>> In article <fs8fll$(E-Mail Removed)>,
>>
>>
>>
>> Richard Tobin <(E-Mail Removed)> wrote:
>> >In article <(E-Mail Removed)>,
>> >John Bode <(E-Mail Removed)> wrote something sensible, logical,
>> >and helpful, starting with:

>>
>> >>Linkers are defined by the platform, not the language;

>>
>> >No, by both.

>>
>> >>there is no C-
>> >>specific linker (AFAIK), just like there is no C++-specific linker or
>> >>Fortran-specific linker or Pascal-specific linker (am I sufficiently
>> >>showing my age?). The same linker can be used for all of the above;

>>
>> >Obviously a sufficiently complicated linker can be used for
>> >everything. But until quite recently most linkers that were adequate
>> >for C were *not* adequate for C++. Gcc's C++ for example had an
>> >associated program "collect2" that provided the linkage features
>> >absent in typical unix linkers (in particular, if I understand
>> >correctly, support for initialisation by C++ constructors).

>>
>> And therefore, I fear deeply for his clique membership.
>> Downfall looks imminent.

>
> Breaking my own rule, but...
>
> TINFC. GTFOY. HTH. HAND.


Could you state the cross section #s in the standard for those please
John :-;
 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      03-25-2008
user923005 <(E-Mail Removed)> writes:

> On Mar 23, 4:16*pm, jacob navia <(E-Mail Removed)> wrote:
> {snip}
> Here is the same thing, more succintly and accurately:
> http://en.wikipedia.org/wiki/Linker
> I guess that anybody wants to program and who is smart enough to
> become a programmer could find it in two seconds.


And anyone who is "smart enough" and "wants to program" can google up
the return code of main() and read enough reviews to know that reading
Knuth is not the way for the average "smart enough" guy to learn
programming. Your point is? And if you have a point would you like to
define just how hard something must be before they are allowed to post
here to ask a question on it and you will deign to answer?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM



Advertisments