How do linkers work?

M

Mark McIntyre

Tony said:
Sorry Keith, I don't really understand what you are saying here.Are you
saying that subjects like this should be cross posted to
comp.lang.whatever (and risk the wrath of the usual suspects) or not be
posted at all?

No, keith is saying that the material isn't topical in CLC, and should
be posted elsewqhere.
I am one year into programming now and hope to make a living out of it
someday. Personally speaking I have zero experience with other languages
outside of C and hence have found Jacob's recent posts about stacks,
debugging and linking very informative

The problem is, NONE of that is generally true in C. It may happen by
coincidence to be true on the specific platform you're using - but one
day you'll move to a different platform, and discover to your horror
that it was all misleading.
- if he had posted them to
comp.lang.fortran or wherever I would have missed them.

I'm one year into a bricklaying course; comments about how to decide
where to put headers and how many wallties to insert would be useful to
me. If I got them in CLC it''d save me the effort of finding a more
appropriate place.
I have learned one hell of a lot here recently just by browsing (when I
get completely stuck I'm sure I'll be asking questions) but have been
getting increasingly pissed off with the "off topic" brigade and the
(seeming) mob of regulars who just bitch about one and other.

That's a shame, because it suggests you've missed a VERY important
aspect of usenet: there are many tens of thousands of groups, each
specialising in something.

Imagine if, instead of magazines for cookery, acupuncture, DIY, home
cooking and microprocessor design, we just had one HUGE magazine
covering everything. Woudl that really be useful?

If you want to learn general programming techniques, comp.programming is
a really good place to hang out. If you want to learn language-specific
stuff, hang out in CLC.
To all: give a thought for us learners.

This is /precisely/ why people correct Jacob - because he's misleading you.
I for one am here for an
education - in the art of C

ok, clc is the right place.
and programming in general.

ok, clc is the /wrong/ place/.
 
F

Flash Gordon

jacob navia wrote, On 25/03/08 20:50:
No, he just showed that when invoked with some
special flags, the msvc compiler produces a single object file
that is linked differently with the system libraries.

Conceptually however, the object file is probably the same as the
other object files. But the model of SEPARATE compilation
does not hold since all source files are thrown together.

In your original post you did not state it is a conceptual model, and as
you become more detailed it moves further away from what happens in real
life in some implementation, such as MSVC with the specified options.
"Resolve all symbols" is what then?

Resolving symbols, what else? Relocating is a separate problem, so
separate that on some systems the resolution of symbols is done at
compile time but the relocation is done at run time.
Reading all the relocation records, and producing a relocatable
executable.

Incorrect, see above.
But you just have no interest in anything else but proving me
wrong. Look the best is then is for you to see:

No, my interest is in stopping the spread of incorrect information.
"jacob is wrong".

Happy now?

I would be if you actually meant it and also desisted from off topic posts.
Great, but they still have dynamic linking.

You are the first person I've seen describe the behaviour of part of an
interpreter as linking. I can't even imagine how it applies to what the
interpreter does when it encounters a call to putc.
Anyway who cares?

A number of people, starting with the authors of C interpreters.
So, all the modules are loaded separatedly each time?
Yes.

It would be quite surprising if they did.

So be surprised.
No, what they do is
to dynamically link the executable that is in disk form.

The dlls/shared objects are linked on the fly when they are
loaded, under windows/linux. You wouldn't say that the
executable doesn't exists isn't it?

You were the one who said the executable is what you get after linking.
Since the linking is done when the program is loaded (until then it has
the name of the function to be called, nothing about where in the
library it is) by your definition the executable is not on disk.

Even MS refers to it as Load-Time Dynamic Linking
http://msdn2.microsoft.com/en-us/library/ms684184(VS.85).aspx

Some systems do more than others at load time. You can see an abstract
of a more serious article about this topic here
http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel1/2/12418/00573670.pdf?temp=x

On Linux, resolving some functions might *never* be done since it is
sometimes done only when the function is called.
No. I said "Resolving all symbols"

Resolving and relocation are separate problems often done at different
times.
In my next installment I will explain how this is done using the
relocation records.

Not all systems use relocation records in any form.
This is wrong.

Where does C require relocation? What relocation occurs in a C
interpreter? What relocation occurs if the code is position independent
(some truly is, as in using relative addressing only) and so does not
require relocation and has no relocation records?
It is relevant. And very relevant, see the questions coming up every
time about linking.

Since you have not produced an article that is generally correct why
would anyone want further information about it?
I am excluding them from this discussion about linkers and linking!

Those implementations have linkers and perform linking so why are they
excluded?
I am NOT excluding them from the language or saying that those
applications aren't valid or whatever your imagination is
constructing here!

You started by claiming to describe linking and linkers, not linking as
done on some implementations by certain linkers. Can you not understand
the difference?

Can you see one part of your article (ignoring the problems mentioned
above) that does not apply to C++, Pascal, ADA, Perl, PHP and a hole
host of other compiled and interpreted languages as well?

Doesn't the fact that your article is just as accurate (and just as
inaccurate) for multiple languages suggest that it belongs in a group
that is not language specific, such as comp.programming? After all, you
are fully aware that such places exist.
 
C

CBFalconer

jacob said:
(e-mail address removed) wrote:
.... snip ...


If you are not interested in the "implementation details" then
please stop this stupid discussion. I want to explain that details
precisely. If you do not want to know anything about them, just
type your commands and forget about the internals

Then please take the implementation specific explanation to
comp.compilers.lcc or some other newsgroup where it is topical.
This is not it.

.... snip mounds of unread junk ...
 
T

Tony Giles

Mark McIntyre wrote:

<snip a lot of good advice plus condescending bullshit about
bricklaying, cookery and the like>

Please note my previous reply to John Bode's comment.

Cheers, Tony.
 
K

Keith Thompson

Tony Giles said:
Mark McIntyre wrote:

<snip a lot of good advice plus condescending bullshit about
bricklaying, cookery and the like>

Please note my previous reply to John Bode's comment.

Please be aware that Usenet is an asynchronous medium; articles do not
necessarily arrive at any given site in a timely manner, or in the
order in which they were posted. Mark may well not have seen your
reply to John Bode.
 
T

Tony Giles

Keith said:
Please be aware that Usenet is an asynchronous medium; articles do not
necessarily arrive at any given site in a timely manner, or in the
order in which they were posted. Mark may well not have seen your
reply to John Bode.
Fair enough, yet another Usenet lesson learned. I assume that Mark's
attempted wit is something you just have to tolerate on Usenet then...
bloody brickies.
Please excuse my original post to your message as I do read it in a
different light now.

Cheers, Tony.
 
A

Antoninus Twink

Thread PLONK

At last! A truly brilliant contribution to the group! CBF has finally
figureed out that if you ignore the threads you're not interested,
instead of spewing a stream of "that's off topic" posts into them, then
the group will be a better place.

Now if only he could convince his former friends in The Clique to follow
this policy...

....and fix his damn signature.


--
 
D

Dik T. Winter

> Flash Gordon wrote: ....
>
> Great, but they still have dynamic linking. Anyway who cares?
>
>
> So, all the modules are loaded separatedly each time?
Indeed.

> It would be quite surprising if they did. No, what they do is
> to dynamically link the executable that is in disk form.

Be surprised. I have worked with such a system where the output from
compilation was immediately used in the linking/loading phase, where
linking and loading in general was *not* separated.
 
E

Ed Prochak

Keith said:
Consider that all compiled languages depend on linkers just as much as
C does. If a post would be just as relevant to comp.lang.whatever as
it is to comp.lang.c, why post it to comp.lang.c rather than
comp.lang.c++ or comp.lang.fortran?

Sorry Keith, I don't really understand what you are saying here.Are you
saying that subjects like this should be cross posted to
comp.lang.whatever (and risk the wrath of the usual suspects) or not be
posted at all?

they should be posted to an appropriate group. comp.programming seems
very appropriate.
[]

To all: give a thought for us learners. I for one am here for an
education - in the art of C and programming in general. For me, topics
as mentioned before are very much on topic. Maybe I should trawl through
comp.lang.endless but I'd rather the one stop on what I am learing!

These topics Navia has been harping on belong to a generic programming
languages group, or a generic OS group. I have suggested
comp.programming but he seems determined on using this group whether
the topic is appropriate or not.

You are not forced to read only one group. There are a wide range of
groups from which to learn.

Again, groups are organized by topic for a reason. These are not AOL
chat rooms where anything goes.

Hope you learned something new today.
Ed
 
E

Ed Prochak

[ several portions from other posts removed to focus only on Navia's
comments about his linker posts.]
If you are not interested in the "implementation details"
then please stop this stupid discussion. I want to explain
that details precisely. If you do not want to know
anything about them, just type your commands
and forget about the internals
And the linker details are C related how?
Linkers do "linking", i.e.
they read all the symbol tables of the object files
assemble the different sections together
Resolve all the symbols
Output an executable.

Whatever *else* they do is of no importance if they do
this.


Not of C but of the linking process.
I am speaking about linking here.
And not about C or C programming.
Glad you cleared that up.
Maybe. I am speaking about the most common situation. Feel free to
explain other situations if you wish.
Which common situation? So much more about linking is related to the
target environment and build environment, and only slightly related to
the source language.
You confirm then, what I said in my previous message.
The object file is there, containing all the
program, that is linked with libraries etc.
So linker specific details, unrelated to C
I use that definition of executable files: relocation.
If not an EPROM file would be an executable file.

In some primitive OSes executable files can be like that.
So what? I use the relocation as definition.
So OS specific, but unrelated to C

I'm glad you cleared this off topic issue up. I'll be watching for
your further linker posts. Since you agree they are not C topical,
where will you post them ?
I suggest comp.programming as appropriate.

Ed
 
J

jacob navia

Ed said:
[ several portions from other posts removed to focus only on Navia's
comments about his linker posts.]
If you are not interested in the "implementation details"
then please stop this stupid discussion. I want to explain
that details precisely. If you do not want to know
anything about them, just type your commands
and forget about the internals
And the linker details are C related how?

Look, this is not the stack discussion. You *could* argue that
since the stack is not mentioned in the standard, speaking
about the stack is off topic. But the linker *is* mentioned
in the standard.

:)

Linking is an *essential* step in each C program you write.
I just can't understand that speaking about linkers is
off topic in a C related group!

If you have nothing to say please do not say it here...
 
R

robertwessel2

Linking is an *essential* step in each C program you write.
I just can't understand that speaking about linkers is
off topic in a C related group!


Linking, as it applies in general to C program development, is
certainly topical. IOW, if you have X in Source1 and Y in Source2,
the resulting program will do Z (or be undefined, or whatever).

The exact internal details of how a particular linker in a particular
tool chain works is *not*.

Any C compiler must have a parser of some sort to separate the
tokens. The standard even mentions it. Are the details of a
particular C compiler's parser implementation relevant here? Again,
no, except perhaps as a clarification to a discussion of the required
behavior.
 
J

jacob navia

Linking, as it applies in general to C program development, is
certainly topical. IOW, if you have X in Source1 and Y in Source2,
the resulting program will do Z (or be undefined, or whatever).

The exact internal details of how a particular linker in a particular
tool chain works is *not*.

I tried to be general in my article. I used my linker
as an example.
Any C compiler must have a parser of some sort to separate the
tokens. The standard even mentions it. Are the details of a
particular C compiler's parser implementation relevant here? Again,
no, except perhaps as a clarification to a discussion of the required
behavior.

And the required behavior in the example I brought?

You think it is not a serious cause of BUGS?

Why you do not even mention that?

If you have nothing to say, do not say it here.
 
P

Peter Nilsson

There's a rather obvious connection. But that doesn't
mean that the mechanics or invocation of linkers is
topical in clc.

jacob navia said:
Look, this is not the stack discussion.

Who said it was.
You *could* argue that since the stack <snip>

is not mentioned in the standard, speaking
about the stack is off topic.

Please take time to read what people actually say.
Exclusive articles on specific hardware stacks or
the actual underlying implementation of the LIFO
construct needed to implement recursive function
calling is discouraged because it is not only
irrelevant to the practice of writing maximally
portable C, it actually confuses many people into
believing that C guarantees certain behaviour when
in fact it doesn't (e.g. left to right evaluation
of arguments.)

That students get hung up on it is because of people
like yourself who tell them to think that it's
terribly important to know what's under the hood,
when in fact it isn't. Observe that programmers of
'higher' 4g languages aren't anywhere near as
focussed on how the language is implemented as people
are with C. That doesn't highlight that C is a
particularly low level language. It highlights that
people studying C tend to learn it badly because they
get easily distracted on pointless irrelevancies
rather than trying to simply write clean and simple
code in the language as is.
But the linker *is* mentioned in the standard.

To be precise, translation phase 8 is mentioned in the
standard. Namely...

All external object and function references are
resolved. Library components are linked to satisfy
external references to functions and objects not
defined in the current translation. All such
translator output is collected into a program image
which contains information needed for execution in
its execution environment.
Linking is an *essential* step in each C program you
write.

No, the 7 previous translation phases are as important
as the 8th. But knowing how those phases are implemented
under the hood _isn't_ essential in writing C code.
I just can't understand that speaking about linkers is
off topic in a C related group!

Because you have no idea what comp.lang.c is really about
and never have! I suspect you only polute it because
comp.compilers.lcc doesn't have the audience you wish to
interact with. So you've decided to take your conversations
into another forum knowing it's off topic.
If you have nothing to say please do not say it here...

Obviously what I and others say is falling on deaf ears
(well eyeballs), but you're not going to bully the group
into changing it to what _you_ want it to be, just because
_you_ want it to be that way.

I've said it before, I'll say it again, I wish you the
very worst of luck in your attempts to undermine and
destroy what is perhaps the _only_ forum that is prepared
to focus exclusively on the core C language for what it
is.

Pure C is a rich enough subject to study in its own right.
If it bores you, then _you_ should leave. But instead
you've made it your mission to destroy it without a care
for the value it's given in the decades previous.

Posts and web pages on stacks and linkers, like the ones
you've given recently are a dime a dozen. Comp.lang.c
is not yet a dime a dozen newsgroup. I hope you never
succeed in making it one.
 
J

jacob navia

Peter said:
That students get hung up on it is because of people
like yourself who tell them to think that it's
terribly important to know what's under the hood,
when in fact it isn't. Observe that programmers of
'higher' 4g languages aren't anywhere near as
focussed on how the language is implemented as people
are with C.

Yes. C is near the machine level, and it is
important that C programmers understand what is
going on under the hood.

I disagree completely with your stated goals of making
people use the language without knowing what is going on
at the basic level in their machine.

I could accept that from somebody programming in C#
or in lisp, or in another language but in C I suppose
that people should be knowledgeable of what they are
doing when they invoke the linker, when they start
the debugger, when they write a line of C.

And even people that use a computer sometimes
could gain from knowledge about what is going on
inside the machine, what an OS is, etc.

It is a completely different philosophy here.
I started with computers because it is FUN, because
I liked to know how they work, how they do what they
do. I never closed myself to new knowledge.

And yes, I think that today's students know far too
little of what is going on within the machine,
about the concepts of code generation, linking, debugging
and similar concepts.

Yes, we can go on discussing

Why doesn't

i= i++;

work?

but then this group is a total bore!

If you do not like my posts just ignore them. I will go
on trying to speak about how the system works. The stack,
the debugger, the linker, and I haven't even started the
assembler, the parser, etc.

And if you think that knowing the details of stuff and discussing about
it is not relevant then explain to me the behavior I flagged.

Both gcc and MSVC linked a flawed program without any warning.

That doesn't ring bells anywhere?
 
J

João Jerónimo

jacob said:
OK, after the stack and the debuggers, let's look a little bit
more in depth into this almost ignored piece of the language,
the linker.

Obviously, the C standard doesn't mention this [1]. And almost
never we discuss it here.

In my C class, we use to talk about system-stacks, separate compilation,
and assembly as a fase of compilation...

Sincerily speaking, I was already aware that the "assembly phase" was an
implementation detail. I thought, however, that the linking phase was a
recognised building phase.

PS: If I'm not in error, I've once read that the C standard recognises
something called "linkage"...

JJ
 
K

Keith Thompson

jacob navia said:
Both gcc and MSVC linked a flawed program without any warning.

That doesn't ring bells anywhere?

If you'd like to discuss the fact that the C standard's requirements
for translation phase 8 (linking) are so lax that they permit some
serious errors to remain undiagnosed, by all means do so. Using the
behavior of particular implementations as examples of what the
standard allows would IMHO be fine in such a discussion. I'd even
encourage you to start a new thread to discuss the issue. (If it
veers into proposals for changes to the language requirements, it
might become more appropriate for comp.std.c; we can deal with that as
it happens.)

It would be appropriate here in comp.lang.c because it would be about
C. It would not be about C++, or Fortran, or Ada, because those
languages have different rules about linking.

A general discussion of "How do linkers work?", on the other hand, *is
not about C*, and therefore does not belong in comp.lang.c. This is
not comp.whatever-jacob-finds-interesting.
 
F

Flash Gordon

jacob navia wrote, On 26/03/08 22:17:
Yes. C is near the machine level, and it is
important that C programmers understand what is
going on under the hood.

Only occasionally, and when it is the discussion about it belongs in a
system specific group because what goes on under the hood is system
specific.
I disagree completely with your stated goals of making
people use the language without knowing what is going on
at the basic level in their machine.

No one is trying to prevent people knowing how their machines work for a
basic level, it is just that the discussion about how specific machines
work belongs on system specific groups.
I could accept that from somebody programming in C#
or in lisp, or in another language but in C I suppose
that people should be knowledgeable of what they are
doing when they invoke the linker, when they start
the debugger, when they write a line of C.

I've only ever needed to know any kind of details about a linker when
writing linker scripts, something that the linkers you are talking about
don't need. Even then I did not need to know the type of information you
are talking about.

You only need to know about the specifics of your implementation when
you are doing implementation specific stuff, which you don't normally
need for the bulk of the code, and when you do that is covered by
implementation specific groups.
And even people that use a computer sometimes
could gain from knowledge about what is going on
inside the machine, what an OS is, etc.

There are groups for discussing all of this, it is just that it is not
*this* group.
It is a completely different philosophy here.
I started with computers because it is FUN, because
I liked to know how they work, how they do what they
do. I never closed myself to new knowledge.

So? This group is for discussing C not for discussing whatever you find fun.

If you do not like my posts just ignore them. I will go
on trying to speak about how the system works. The stack,
the debugger, the linker, and I haven't even started the
assembler, the parser, etc.

So you intend to continue making inaccurate off-topic posts even though
you *know* there are other groups where your posts would be topical.
And if you think that knowing the details of stuff and discussing about
it is not relevant then explain to me the behavior I flagged.

It isn't.
Both gcc and MSVC linked a flawed program without any warning.

That doesn't ring bells anywhere?

Yes, it is the same as lots of other instances of undefined behaviour
and it is well known behaviour. Just as well known as i=++i being
undefined. I've even posted about the switch to change the behaviour in
gcc several times over the past several years, although often I've not
bothered to find the specific switch only mentioned it exists.
 
E

Ed Prochak

Ed said:
[ several portions from other posts removed to focus only on Navia's
comments about his linker posts.]
If you are not interested in the "implementation details"
then please stop this stupid discussion. I want to explain
that details precisely. If you do not want to know
anything about them, just type your commands
and forget about the internals
And the linker details are C related how?

Look, this is not the stack discussion. You *could* argue that
since the stack is not mentioned in the standard, speaking
about the stack is off topic. But the linker *is* mentioned
in the standard.

:)

Linking is an *essential* step in each C program you write.
I just can't understand that speaking about linkers is
off topic in a C related group!

If you have nothing to say please do not say it here...

linking os an essential step in any program. so why discuss it only in
comp.lang.c?
Editing is also an essential step in producing a C program. So are you
suggesting discussions of emacs, VI, and WORDPAD are appropriate? I do
not think they are. Are you willing to open the discussion area that
wide?

A topic line has to be drawn somewhere. I and others draw a much
tighter circle that you do. I wish we could convince you that leaving
it too wide may bring an unmanageable volume resulting in the eventual
loss of usefulness of this group for all. Given that you seem to
refuse that argument, you still need to respond to the argement that
There are better places for the topics you want.

How's this for a solution:
post the linker discussion in comp.programming
post a BRIEF note in comp.lang.c that the discussion moved there. (be
sure to set followup-to: comp.programming)
optionally post that brief note in the other language groups

then the C programmers that are interested in linker discussions can
find it.
the topic is discussed in the appropriate group
other linker experts can contribute.
other programmers can participate.


you will have your moment in the sun, and it could be a very
interesting discussion. You keep saying the linker discussion must be
here, but Why do you not want to follow usenet netiquette and put the
discussion where it belongs, comp.programming?

Ed
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top