Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

How do linkers work?

 
 
santosh
Guest
Posts: n/a
 
      03-24-2008
Richard Heathfield wrote:

> Tony Giles said:
>
> <snip>
>
>> 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 - if he had
>> posted them to comp.lang.fortran or wherever I would have missed
>> them.

>
> How can you tell whether the information he has presented is
> authoritative? If such article are posted in the kind of group where
> they are topical, they stand a much higher chance of getting proper
> peer review.
>
> <snip>
>
>> To all: give a thought for us learners.

>
> We do. We assume you come here to learn more about C, and as a group
> we provide an astoundingly authoritative resource - on C. Not on
> debuggers, linkers, stacks, and the like. If you want peer-reviewed,
> authoritative articles on those subjects, you'd be better off finding
> a group where debuggers, linkers, and stacks are topical, because
> that's where you're most likely to find the experts.


The problem is there seem to be no general group on Usenet for linkers,
debugging etc. However I agree that they are more topical in groups
like comp.programming or comp.misc more than in groups like c.l.c or
c.l.fortran or such.

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

> Richard Heathfield wrote:
>
>> Tony Giles said:
>>
>> <snip>
>>
>>> 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 - if he had
>>> posted them to comp.lang.fortran or wherever I would have missed
>>> them.

>>
>> How can you tell whether the information he has presented is
>> authoritative? If such article are posted in the kind of group where
>> they are topical, they stand a much higher chance of getting proper
>> peer review.
>>
>> <snip>
>>
>>> To all: give a thought for us learners.

>>
>> We do. We assume you come here to learn more about C, and as a group
>> we provide an astoundingly authoritative resource - on C. Not on
>> debuggers, linkers, stacks, and the like. If you want peer-reviewed,
>> authoritative articles on those subjects, you'd be better off finding
>> a group where debuggers, linkers, and stacks are topical, because
>> that's where you're most likely to find the experts.

>
> The problem is there seem to be no general group on Usenet for linkers,
> debugging etc. However I agree that they are more topical in groups
> like comp.programming or comp.misc more than in groups like c.l.c or
> c.l.fortran or such.


Nonsense.

Basic common sense would tell any experienced IT person that comp.lang.c
would be full of C programmers who hopefully have a view on the tools of
the trade - namely the things you mention above.

If you (not you personally) do not wish to help - then don't. Leave it
to those of us who will.
 
Reply With Quote
 
 
 
 
ymuntyan@gmail.com
Guest
Posts: n/a
 
      03-24-2008
On Mar 24, 8:10 am, Eric Sosman <(E-Mail Removed)> wrote:
> jacob navia wrote:
> > 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.
> > [...]

>
> Your copy of the Standard must be incomplete. It appears
> you haven't seen sections 5.1.1.1, 5.1.1.2, 6.2.2, and 6.9.


He *is* right. Try to quote more than one place which mentions
a *linker*.

Of course there is a good reason for not mentioning linkers,
they are not mandatory and translation phases are just a model,
they need not to be separated, there need not to be a linker,
preprocessor or whatever, and so on. But, you know, there is
no stack either

Yevgen
 
Reply With Quote
 
John Bode
Guest
Posts: n/a
 
      03-24-2008
On Mar 24, 2:23 am, Tony Giles <(E-Mail Removed)> wrote:
> Keith Thompson wrote:
> > [...]

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


Linkers are defined by the platform, not the language; 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;
in fact, most linkers can link modules compiled from different
languages. So any discussion of a particular linker is orthogonal to
discussion of a particular language. Not to mention that there are C
interpreters available, which eliminate linkers from the process
completely.

Keith's point is that linker discussions are just as topical in c.l.f
or c.l.c++ as they are here, which is not very. Again, the linker is
defined by the platform, not the language; as Jacob points out, object
file formats vary (ELF vs. COFF vs. OMF), linker parameters and
operations vary (knowing how to drive ld doesn't tell you much about
driving other linkers). And *none* of it is defined by, or really
relevant to, the C *language*, which is allegedly the focus of this
group, much as Jacob and a few others would like to believe otherwise.

> 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 - if he had posted them to
> comp.lang.fortran or wherever I would have missed them.
>


The danger is believing that Jacob's descriptions are universally
applicable; they are not. As others have pointed out, there are
implementations of C that do not rely on a hardware stack. There's a
disease common to C programmers; in the '80s it was call "All The
World's A VAX" syndrome (today it would be called "All The World's A
Windows/x86 PC" syndrome). It's the inability of many programmers to
distinguish between behavior mandated by the language definition vs.
behavior that's a result of the particular implementation; i.e., they
don't know where the language ends and the platform begins. It's the
source of a lot of bad habits that plague the industry. And Jacob's
articles, while informative, run the danger of perpetuating the
problem.

Speaking as someone who's had to support multiple platforms
concurrently (try getting something to work on five flavors of Unix
*and* Windows *and* OS/2 *and* AS/400 sometime), knowing where the
language ends and the platform begins is a vital skill to have.

> 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 ****ed off with the "off topic" brigade and the
> (seeming) mob of regulars who just bitch about one and other.
>


First of all, it's unreasonable to expect this group (or any other) to
cover any conceivable topic that's tangentially related to C
programming. The reason most of us try to redirect people is that a)
there are other newsgroups focused on their particular issue, so that
they'll get more and better quality help in those newsgroups, and b)
by trying to keep the discussion here focused on a single topic, this
group can cultivate a similar depth of expertise. I'd rather this
group be an inch wide and a mile deep than vice-versa. Sort of like
the difference between K&R2 and anything by Schildt.

Yes, some of us are a bit surly. That's unfortunate, but it's one of
the occupational hazards of writing C code for a living (that and the
permanent brain damage). If you don't like what those people have to
say, well, that's what killfiles are for. It's a lesson that has
taken me longer than it should have to learn, but life's too short to
get ****ed off over what someone said on the internet.

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


Again, think of it in terms of reference manuals; I have a book on
multithreaded programming on Windows in C++ somewhere. Does this
manual cover everything about C++ *and* Windows *and* threads? No.
It covers enough of C++ and Windows to provide context, but it won't
answer any questions about those topics in any depth. If you get
stuck on a C++ concept, you go to a different manual.

That's kind of how you need to look at technical newsgroups.
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      03-24-2008
In article <(E-Mail Removed)>,
John Bode <(E-Mail Removed)> wrote:

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

>So any discussion of a particular linker is orthogonal to
>discussion of a particular language.


No. C imposes certain requirements on a linker which my be more than
those required for some other languages and less than those required
for others.

-- Richard
--
:wq
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      03-24-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> On Mar 24, 8:10 am, Eric Sosman <(E-Mail Removed)> wrote:
>> jacob navia wrote:
>>> 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.
>>> [...]

>> Your copy of the Standard must be incomplete. It appears
>> you haven't seen sections 5.1.1.1, 5.1.1.2, 6.2.2, and 6.9.

>
> He *is* right. Try to quote more than one place which mentions
> a *linker*.


<Shrug.> The Standard doesn't mention a multiplier,
either, but that doesn't interfere with its defining of
multiplication operators. The Standard tries very hard
to describe *what* must occur without describing *how*
the occurrence is brought about; in modern jargon, it
describes the "interface" and not the "implementation."

The Standard requires that identical identifiers with
external linkage must refer to the same object or function
throughout the execution of the program. The Standard does
not specify any particular technique to make this happen;
it just describes the required outcome. Likewise, it says
that translation units can be translated separately and
later combined into a single program; the implementation
can use any technique it finds suitable, so long as they
meet the Standard's requirements.

The sections of the Standard that deal with these
matters, taken together, amount to a high-level requirements
specification for a "linker," and that's all a user of the
language needs. An implementor needs considerably more, of
course -- but then, the implementor also has to worry about
how to recognize and remove comments, how to perform macro
substitution, how to get stdin to be opened before main()
starts, and a mighty host of other important details. There
is no reason to single out the link-editing process any more
than to single out the mechanisms of malloc().

--
(E-Mail Removed)
 
Reply With Quote
 
lawrence.jones@siemens.com
Guest
Posts: n/a
 
      03-24-2008
Tony Giles <(E-Mail Removed)> wrote:
>
> 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?


I think he's saying they should be posted in a generic programming group
(like comp.programming).

-Larry Jones

I must have been delirious from having so much fun. -- Calvin
 
Reply With Quote
 
robertwessel2@yahoo.com
Guest
Posts: n/a
 
      03-24-2008
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.

I compiled a C program with MSVC and the resulting object file has
*none* of those things in it, except in an indirect sort of way. I
happened to use /GL, for link time code generation, which results in
an intermediate representation (basically whatever parse or DAG tree
MS uses internally) being stored in the "object" file, and the back
end of the compiler is run by the linker on the whole collection of
partially compiled programs (which allows the back end to do
considerable inter-translation unit optimization). In fact the
"object" file contains the fully qualified path to c2.dll.

Nor is link-time code generation uncommon.
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      03-24-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.
>
> I compiled a C program with MSVC and the resulting object file has
> *none* of those things in it, except in an indirect sort of way.


You are dreaming. Suppose the following program:

#include <stdio.h>
#ifdef __LCC__
#include <stdint.h>
#else
typedef unsigned __int64 uint64_t;
#endif
#include <stdlib.h>

int main()
{

int intLoop; //Variable Just For Looping
uint64_t UINT64_Test; //uint64_t variable
uint64_t *UNIT64_Array_Test; //uint64_t 1 dimensional array

//allocate 1 element for out array
UNIT64_Array_Test = (uint64_t *) calloc(1,sizeof(uint64_t));


//initialise variable and our array element
UINT64_Test = 4294967295;
UNIT64_Array_Test[0] = 4294967295;

//Output to confirm variable + our array element populated OK
printf("UINT64_Test = %llu\n",UINT64_Test);
printf("UNIT64_Array_Test[0] = %llu\n",UNIT64_Array_Test[0]);

//Increment both the array and the variable... 100000 times
for(intLoop=0;intLoop < 1;intLoop++){
UINT64_Test++;
UNIT64_Array_Test[0]++;
}

//Output the results
printf("UINT64_Test = %llu\n",UINT64_Test);
printf("UNIT64_Array_Test[0] = %llu\n",UNIT64_Array_Test[0]);


//Secondary test... confirm array is actually capable of
holding data...
UNIT64_Array_Test[0] = 1234567890123456789;
printf("UNIT64_Array_Test[0] = %llu\n",UNIT64_Array_Test[0]);

//and add one to the new large value...
UNIT64_Array_Test[0]++;
printf("UNIT64_Array_Test[0] = %llu\n",UNIT64_Array_Test[0]);

return 0;
}
---------------------------------------------------------------------------
My utility "pedump" shows the contents of object files.
D:\lcc\mc71\test>pedump /summary tll.obj
tll.obj 1513 bytes, linked Mon Mar 24 20:25:53 2008

Section Name Size
01 .drectve 47
02 .debug$S 104
03 .data 173
04 .text 270
05 .pdata 12
06 .xdata 8

Sections "data" and "text" (code) are well present.
I can see the symbol table:


Symbol Table - 25 entries of 18 bytes each (* = auxiliary symbol)
Indx Name Value Section cAux Type Storage
---- -------------------- -------- ---------- ----- ------- --------
0000 @comp.id 07194151 sect:ABS aux:0 type:00 st:STATIC
0001 .drectve 00000000 sect:1 aux:1 type:00 st:STATIC
* Section: 0000 Len: 00047 Relocs: 00000 LineNums: 00000
0003 .debug$S 00000000 sect:2 aux:1 type:00 st:STATIC
* Section: 0000 Len: 00104 Relocs: 00000 LineNums: 00000
0005 .data 00000000 sect:3 aux:1 type:00 st:STATIC
* Section: 0000 Len: 00173 Relocs: 00000 LineNums: 00000
0007 $SG3422 00000000 sect:3 aux:0 type:00 st:STATIC
0008 $SG3423 00000024 sect:3 aux:0 type:00 st:STATIC
0009 $SG3427 00000056 sect:3 aux:0 type:00 st:STATIC
0010 $SG3428 00000080 sect:3 aux:0 type:00 st:STATIC
0011 $SG3429 00000112 sect:3 aux:0 type:00 st:STATIC
0012 $SG3430 00000144 sect:3 aux:0 type:00 st:STATIC
0013 .text 00000000 sect:4 aux:1 type:00 st:STATIC
* Section: 0000 Len: 00270 Relocs: 00013 LineNums: 00000
0015 main 00000000 sect:4 aux:0 type:32 st:EXTERNAL
0016 .pdata 00000000 sect:5 aux:1 type:00 st:STATIC
* Section: 0000 Len: 00012 Relocs: 00003 LineNums: 00000
0018 $pdata$main 00000000 sect:5 aux:0 type:00 st:STATIC
0019 .xdata 00000000 sect:6 aux:1 type:00 st:STATIC
* Section: 0000 Len: 00008 Relocs: 00000 LineNums: 00000
0021 $unwind$main 00000000 sect:6 aux:0 type:00 st:STATIC
0022 printf 00000000 sect:UNDEF aux:0 type:32 st:EXTERNAL
0023 calloc 00000000 sect:UNDEF aux:0 type:32 st:EXTERNAL
0024 $LN6 00000000 sect:4 aux:0 type:00 st:LABEL

String Table
------------
Length: 29(d)
[ 1 4 16] "$pdata$main"
[ 2 16 29] "$unwind$main"


And I can see the relocations

Section 04 (.text) relocations

Address Type Symbol Index Symbol Name
------- ---- ------------ ----- ----
15 ???_4 23 calloc
55 ???_4 7 $SG3422
60 ???_4 22 printf
75 ???_4 8 $SG3423
80 ???_4 22 printf
156 ???_4 9 $SG3427
161 ???_4 22 printf
176 ???_4 10 $SG3428
181 ???_4 22 printf
214 ???_4 11 $SG3429
219 ???_4 22 printf
254 ???_4 12 $SG3430
259 ???_4 22 printf

You are just spreading MISINFORMATION.


I
> happened to use /GL, for link time code generation, which results in
> an intermediate representation (basically whatever parse or DAG tree
> MS uses internally) being stored in the "object" file, and the back
> end of the compiler is run by the linker on the whole collection of
> partially compiled programs (which allows the back end to do
> considerable inter-translation unit optimization). In fact the
> "object" file contains the fully qualified path to c2.dll.
>


This is a CONFIRMATION of what I am saying!

Object files can be generated at link time, but conceptually
they contain the same stuff.

There are versions of lcc-win that do not generate any object file
or even executable file, they generate code "on the fly" and execute
it immediately.

So What?

Are you going to argue then that "executable files" do not exist?


> Nor is link-time code generation uncommon.


It doesn't matter from the standpoint of the conceptual
framework we are discussing.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
robertwessel2@yahoo.com
Guest
Posts: n/a
 
      03-24-2008
On Mar 24, 2:33*pm, jacob navia <(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.

>
> > I compiled a C program with MSVC and the resulting object file has
> > *none* of those things in it, except in an indirect sort of way. *

>
> You are dreaming. Suppose the following program:
>
> #include <stdio.h>
> #ifdef __LCC__
> #include <stdint.h>
> #else
> typedef unsigned __int64 uint64_t;
> #endif
> #include <stdlib.h>
>
> int main()
> {
>
> * * * * *int intLoop; //Variable Just For Looping
> * * * * *uint64_t UINT64_Test; //uint64_t variable
> * * * * *uint64_t *UNIT64_Array_Test; //uint64_t 1 dimensional array
>
> * * * * *//allocate 1 element for out array
> * * * * *UNIT64_Array_Test = (uint64_t *) calloc(1,sizeof(uint64_t));
>
> * * * * *//initialise variable and our array element
> * * * * *UINT64_Test = 4294967295;
> * * * * *UNIT64_Array_Test[0] = 4294967295;
>
> * * * * *//Output to confirm variable + our array element populated OK
> * * * * *printf("UINT64_Test = %llu\n",UINT64_Test);
> * * * * *printf("UNIT64_Array_Test[0] = %llu\n",UNIT64_Array_Test[0]);
>
> * * * * *//Increment both the array and the variable... 100000 times
> * * * * *for(intLoop=0;intLoop < 1;intLoop++){
> * * * * * * * * *UINT64_Test++;
> * * * * * * * * *UNIT64_Array_Test[0]++;
> * * * * *}
>
> * * * * *//Output the results
> * * * * *printf("UINT64_Test = %llu\n",UINT64_Test);
> * * * * *printf("UNIT64_Array_Test[0] = %llu\n",UNIT64_Array_Test[0]);
>
> * * * * *//Secondary test... confirm array is actually capable of
> holding data...
> * * * * *UNIT64_Array_Test[0] = 1234567890123456789;
> * * * * *printf("UNIT64_Array_Test[0] = %llu\n",UNIT64_Array_Test[0]);
>
> * * * * *//and add one to the new large value...
> * * * * *UNIT64_Array_Test[0]++;
> * * * * *printf("UNIT64_Array_Test[0] = %llu\n",UNIT64_Array_Test[0]);
>
> * * * * *return 0;}
>
> ---------------------------------------------------------------------------
> My utility "pedump" shows the contents of object files.
> D:\lcc\mc71\test>pedump /summary tll.obj
> tll.obj 1513 bytes, linked Mon Mar 24 20:25:53 2008
>
> Section Name * * * Size
> * * 01 * .drectve * 47
> * * 02 * .debug$S * 104
> * * 03 * .data * * *173
> * * 04 * .text * * *270
> * * 05 * .pdata * * 12
> * * 06 * .xdata * * 8
>
> Sections "data" and "text" (code) are well present.
> I can see the symbol table:
>
> Symbol Table - 25 entries of 18 bytes each (* = auxiliary symbol)
> Indx Name * * * * * * * * Value * *Section * *cAux *Type * *Storage
> ---- -------------------- -------- ---------- ----- ------- --------
> 0000 @comp.id * * * * * * 07194151 sect:ABS * aux:0 type:00 st:STATIC
> 0001 .drectve * * * * * * 00000000 sect:1 * * aux:1 type:00 st:STATIC
> * * * * Section: 0000 *Len: 00047 *Relocs: 00000 *LineNums: 00000
> 0003 .debug$S * * * * * * 00000000 sect:2 * * aux:1 type:00 st:STATIC
> * * * * Section: 0000 *Len: 00104 *Relocs: 00000 *LineNums: 00000
> 0005 .data * * * * * * * *00000000 sect:3 * * aux:1 type:00 st:STATIC
> * * * * Section: 0000 *Len: 00173 *Relocs: 00000 *LineNums: 00000
> 0007 $SG3422 * * * * * * *00000000 sect:3 * * aux:0 type:00 st:STATIC
> 0008 $SG3423 * * * * * * *00000024 sect:3 * * aux:0 type:00 st:STATIC
> 0009 $SG3427 * * * * * * *00000056 sect:3 * * aux:0 type:00 st:STATIC
> 0010 $SG3428 * * * * * * *00000080 sect:3 * * aux:0 type:00 st:STATIC
> 0011 $SG3429 * * * * * * *00000112 sect:3 * * aux:0 type:00 st:STATIC
> 0012 $SG3430 * * * * * * *00000144 sect:3 * * aux:0 type:00 st:STATIC
> 0013 .text * * * * * * * *00000000 sect:4 * * aux:1 type:00 st:STATIC
> * * * * Section: 0000 *Len: 00270 *Relocs: 00013 *LineNums: 00000
> 0015 main * * * * * * * * 00000000 sect:4 * * aux:0 type:32 st:EXTERNAL
> 0016 .pdata * * * * * * * 00000000 sect:5 * * aux:1 type:00 st:STATIC
> * * * * Section: 0000 *Len: 00012 *Relocs: 00003 *LineNums: 00000
> 0018 $pdata$main * * * * *00000000 sect:5 * * aux:0 type:00 st:STATIC
> 0019 .xdata * * * * * * * 00000000 sect:6 * * aux:1 type:00 st:STATIC
> * * * * Section: 0000 *Len: 00008 *Relocs: 00000 *LineNums: 00000
> 0021 $unwind$main * * * * 00000000 sect:6 * * aux:0 type:00 st:STATIC
> 0022 printf * * * * * * * 00000000 sect:UNDEF aux:0 type:32 st:EXTERNAL
> 0023 calloc * * * * * * * 00000000 sect:UNDEF aux:0 type:32 st:EXTERNAL
> 0024 $LN6 * * * * * * * * 00000000 sect:4 * * aux:0 type:00 st:LABEL
>
> String Table
> ------------
> Length: 29(d)
> [ *1 * * 4 * *16] "$pdata$main"
> [ *2 * *16 * *29] "$unwind$main"
>
> And I can see the relocations
>
> Section 04 (.text) relocations
>
> Address *Type * *Symbol Index Symbol Name
> ------- *---- * *------------ ----- ----
> 15 * * * ???_4 * * * * *23 * calloc
> 55 * * * ???_4 * * * * * 7 * $SG3422
> 60 * * * ???_4 * * * * *22 * printf
> 75 * * * ???_4 * * * * * 8 * $SG3423
> 80 * * * ???_4 * * * * *22 * printf
> 156 * * *???_4 * * * * * 9 * $SG3427
> 161 * * *???_4 * * * * *22 * printf
> 176 * * *???_4 * * * * *10 * $SG3428
> 181 * * *???_4 * * * * *22 * printf
> 214 * * *???_4 * * * * *11 * $SG3429
> 219 * * *???_4 * * * * *22 * printf
> 254 * * *???_4 * * * * *12 * $SG3430
> 259 * * *???_4 * * * * *22 * printf
>
> You are just spreading MISINFORMATION.
>
> I
>
> > happened to use /GL, for link time code generation, which results in
> > an intermediate representation (basically whatever parse or DAG tree
> > MS uses internally) being stored in the "object" file, and the back
> > end of the compiler is run by the linker on the whole collection of
> > partially compiled programs (which allows the back end to do
> > considerable inter-translation unit optimization). *In fact the
> > "object" file contains the fully qualified path to c2.dll.

>
> This is *a CONFIRMATION of what I am saying!
>
> Object files can be generated at link time, but conceptually
> they contain the same stuff.
>
> There are versions of lcc-win that do not generate any object file
> or even executable file, they generate code "on the fly" and execute
> it immediately.
>
> So What?
>
> Are you going to argue then that "executable files" do not exist?
>
> > Nor is link-time code generation uncommon.

>
> It doesn't matter from the standpoint of the conceptual
> framework we are discussing.



Oh, it's a *conceptual framework.*

So those ".obj" files the beginning user, who you claim you're
attempting to educate, sees are just artifacts of the implementation,
and are not the "real" object files, which, may, in fact, not ever
physically exist at all? You mean like the use of a hardware stack is
an artifact of a particular implementation, commonly used to implement
the LIFO nesting of activation records that is required by the
language?

An even if we accept this notion of a conceptual framework, the object
file you're describing doesn't typically exist on a translation-unit
basis, rather, the "internal" object file that's created is typically
a composite of *all* the translation units.

If you were to throw a few qualifiers into the mix, there would likely
be many fewer objections to what you're posting.

As to executable files, I'm not sure they need to exist. A compiled
program burned into a ROM probably doesn't meet many people's
definition of an executable file, nor does the ROM image file,
although both of those can be debated. I've also used systems, not
with C, but other compiled languages, where the linker had a "link-and-
run" option, where it would execute the program immediately upon
linking, and would never write anything like a traditional executable
to disk.

And why, oh, why, did you feel compelled to post an example of the
data in an object file when compiled *without* runtime linking, when I
specifically said that it was *with* runtime linking that the
traditional object file information was not present?
 
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