c program binary/image in memory

[Keith Thompson]

Flash Gordon a écrit :

No, I do not agree.

C is a low level systems language,

Agreed, mostly.

and as such, it is important to
be clear of the usage and the works of this mysterious tool called
THE LINKER.

That doesn't follow.

When we talk about the compiler, for example, we discuss the fact that
it has to recognize and process C source code in accordance with the
grammar and other requirements of the C language standard. We don't
talk about whether the parser is table-driven or uses recursive
descent, what the symbol table looks like, and so forth. Such details
might be interesting, but they really have nothing to do with the C
programming language, which is what we discuss here in comp.lang.c.
(There is a comp.compilers newsgroup where such discussions would be
perfectly topical; there are also newsgroups for gcc and lcc.)

Your own discussion of how the linker works is equally off-topic here.
Much of what you describe is likely to be very different on different
systems. You should at least have acknowledged that.

I'm sure you have a copy of the C standard. Whatever it says about
linking is what's topical here. Anything it doesn't mention can
potentially vary from one system to another, and is more appropriate
for a system-specific newsgroup.

This part of the system is as important as the compiler actually,
but will never explained and never mentioned anywhere. This is not
correct. C programs DO have the distinction between uninitialized
data areas and initialized ones, and that is even specified in the
standard. (The uninitialized ones should be set to zero).

No, the C standard talks about initialized and uninitialized
*objects*. There is no mention of "areas". Uninitialized global and
static objects are initalized to 0 *converted to the appropriate
type*. Though a typical implementation might group these all into a
single area and initialize the area to all-bits-zero, that won't work
if all-bits-zero doesn't happen to be a valid representation a null
pointer or a floating-point 0.0.

There *is* always a section of the program that is reserved for
the machine instructions the circuit understands. There is almost always
a section for the initialized data, and the uninitialized data.

What is a "section"? Please answer based on references to the C
standard, not on your knowledge of MS Windows on x86-based systems.

I think explaining this pertains to the C language, actually I think it
is an essential part that will often be neglected, treating the
compilation system as a magic black box that must be used
without any further understanding.

No, this does not pertain to the C language. On systems where it's
valid, it could pertain to *any* compiled language.

Think about this. Everything you mentioned could apply to programs
written in C, C++, Fortran, Pascal, or Ada on a win32 system. None of
necessarily applies to programs written in C, C++, Fortran, Pascal, or
Ada on an IBM AS/400 system. What does that tell you about where it
might be topical?

 

[tedu]

tedu a écrit :

have you tried to load xlisp?

It is a lisp interpreter written in C.

no, but i've found very few C programs that actually limit themselves
to just C (haven't looked at xlisp, so i'm just guessing). I don't
have thetis (the interpreter) anymore, but you can read about it at
http://portal.acm.org/citation.cfm?id=236452.236560

 

[Jordan Abel]

i did some of my C programming in a C interpreter written in java.
understanding the mysterious linker was a non-issue.

Phase 8 (which is, more or less, what the unix jargon term "linker"
refers to) may be more or less mysterious in some systems than in
others, but there are some implementation-defined aspects that anyone
does need to understand. For example, some systems consider any two
external identifiers beginning with the same six [possibly
case-insensitive] characters, or some larger number, to be equivalent.

 

[Keith Thompson]

Flash Gordon a écrit :

Sure, why not?

But when ASKED (as the original poster asked) why not learn?

Because it has nothing to do with the C programming language. Take
another look at the name of this newsgroup.

If you want to talk about linkers and bss and data segments, nobody
will stop you. If you wan't to talk about bicycles and hang gliders,
nobody will stop you. Just find an appropriate place to do it.

I think knowing the concepts behind those section is important
specially if you not only want to use the compiler as a black
box, but also UNDERSTAND what is going on. But as I said before
this is a matter of personal opinion.

Nobody is necessarily saying that it's not important to know this
stuff (though you can do a lot of C programming without knowing any of
it). The issue is topicality, not importance.

[...]

No, it is just that instead of the operating system+linker doing that,
the program itself does it, before starting main().

You will agree with me howevere, that after that phase of the program is
done, the data section is there and there is a sequential series
of memory locations containing the representation of 488776 ok?

No, I do not agree that there necessarily has to be something called a
"data section", or even something comparable with a different name.
There will likely be an object in memory somewhere. Its location
relative to any other object in memory is system-specific.

 

[Flash Gordon]

Flash Gordon a écrit :

Sure, why not?

But when ASKED (as the original poster asked) why not learn?

Learning is fine and there are lots of things I want to learn. However,
that does not make *any* of them topical on this group, and the details
of how linkers work is *not* topical on this group.

I think knowing the concepts behind those section is important
specially if you not only want to use the compiler as a black
box, but also UNDERSTAND what is going on. But as I said before
this is a matter of personal opinion.

Which does not make it topical here.

The names of the section are irrelevant. Microsoft doesn't even call
them section, they call them "segments".

Whatever. What *is* important to know is that code, data, and
uninitialized data are the different parts of a C program.

They may be on *your* implementation, but they are not on all of the
implementations I have used. Specifically, both initialised *and*
uninitialised data get placed in the *same* section on some systems.

No, it is just that instead of the operating system+linker doing that,
the program itself does it, before starting main().

You will agree with me howevere, that after that phase of the program is
done, the data section is there and there is a sequential series
of memory locations containing the representation of 488776 ok?

I agree that when the program starts the variable has the appropriate
value, but that has nothing to do with what section it is in. I've
worked on systems where there was no separate section for variables with
explicit initialised as compared to those without. I.e., there was *no*
section like the bss section. Also, on the system I mention putting the
initialised data in to the appropriate place is *not* done by the
linker. In any case, this is done by the startup code which is a
completely separate thing from the linker.

By the way, I did that for an embedded system I was working for
last year. The ROM initialized data must be copied to the RAM by
the startup when it is not declared "const".

Yet despite having worked on such systems you still insist on posting as
if everything worked in a similar way to Windows and your compiler.

What always surprises me is how much people here *suppose* I am doing
in constrast to what I am really doing!

Yes, Mr "Gordon", the world is much more complex than you think
and jacob could very well know more than what you think about embedded
systems, specially Analog Devices 16 bit based ones!

Wow. You've worked on two whole processors and post here as if only one
exists. That's as many as I use every day now that I've cut down.

As I said in my previous message (and repeat now) the 3 sections
I mentioned are only the MINIMAL ones!

and you got that wrong. I've worked on systems with only two sections
and even described part of one of them to you. On that system calling
them sections or segments is actually misleading, since what you
actually have is two completely different memory spaces where you even
have a pin on the chip so it can tell the external hardware which memory
space it is accessing, it being a Harvard Architecture system. And when
I say separate, that means a data pointer literally cannot access
program space whatever you do to it even if you write the program in
machine code.

Yes, then it is the program that replaces the OS, and this
distinction blurrs somehow.

On some of them systems the distinction is much stronger than it is in
Windows.

In any case, even if you *can* find something common across all the
systems everyone here uses, unless it is something covered by the C
standard it is not on topic here.

 

[CBFalconer]

Flash Gordon a écrit :
.... massive snippage ...

Sure, why not?

But when ASKED (as the original poster asked) why not learn?

Because it is clearly off-topic in this newsgroup, as you very well
know. Your continuous off-topic postings are only encouraging
newbies and googlies to further pollute the newsgroup.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[Dik T. Winter]

> I am not speaking about linker options, I am speaking about what the
> linker DOES.

O. What does the linker do?

> Obviously the bss/text/data sections can be named differently. Microsoft
> uses the terminology "segment" instead of "section", for instance.
>
> The semantics are the same.

I am surprised. But those semantics are not necessarily present on all
systems. I have used one system (for quite a long time) where the
compiler write out a file containing different segments, where each
segment contained the object code for a subroutine and possible data
sections, in addition there was a segment that contained the data
segments for the overall input file.

There was no specific linker, there was a linking loader. I.e. when
you wanted to execute your code you entered as command the name of
the output file of the compilation, the linking loader would come in,
do all linking needed, and would start execution. It was possible to
instruct the linking loader to output the executable as it would have
started, but in most cases that was not done. Linking and starting
execution took at most milliseconds.

 

[Dik T. Winter]

> Ingo Menger a écrit :
Why?

>
> And it does that each time you access that variable... How clever

Why? The constant 488776 is used only once in your program, on
initialization of 'a'.

> And what does it when you ask for the address of that integer like
> int *p=&a;
> ???

It just takes the addres of the variable to which the constant has
been assigned.

So, why should that constant be somewhere in the executable? I have
used one system where such an initialization would be coded as:
load-high r1, 30
add r1, -2744
store r1, a
(Constants could be coded as signed 16 bits quantities in the
instructions. Registers were 32 bits.)
You inevitably show your ignorance of processors other than Intel
and operating systems other than Microsoft.

 

[Emmanuel Delahaye]

tele-commuter a écrit :

I want to understand how exactly is an image(compiled
c code and loaded into memory) stored in memory.

Once the C-source is compiled, it's no longer a C-program. It becomes
some code file. Details belong to the implementation and are of course
not defined by the standard.

What exactly is a linker script?

None of the other question are C-relevant. Please post to a newsgroup
dedicated to your platform.