c program binary/image in memory

[tele-commuter]

Hi folks,

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

What exactly is a linker script?

I work with a lot of c code on a daily basis but I really
don't understand :

How exactly the sections
like "text,bss,data etc."
work?

What exactly are they?

I believe the linker script describes this layout.

What exactly is a 'bundled image'?

What exactly is 'microcode'?
What exactly is 'firmware'?

I admit I use these terms myself pretty often,but
without much clarity.

Anyways any information or pointers(internet urls) in
this regard would be very helpful.

If it helps,my work involves a lot of driver code
in C on systems using MIPS processors.

Thanks a bunch..

[santosh]

tele-commuter wrote:

Hi folks,

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

None of your questions are topical to this newsgroup, which deals only
with ISO standard C.

A good starting link:

http://www.iecc.com/linker/

[jacob navia]

tele-commuter a écrit :

Hi folks,

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

What exactly is a linker script?

This is an extension of the GNU linkers that allows
GNU people to configure their linker. Normal users
are not supposed to use that, at least I didn't understand
anything about it. This is GNU specific, so off topic
here.
I work with a lot of c code on a daily basis but I really
don't understand :

How exactly the sections
like "text,bss,data etc."
This sections map following parts of the language:

1) The "text" section is the translated output of
the compiler, the program text. For instance

int fn(void) { /* ... */

the sequence of instructions in this function will be stored
in the "text" section. This section is normally not
writable.

2) The bss section implements the zero initialized data. For instance
when you write

int b[23];

This array will be mapped into the bss section. This section will
be zeroed by the operating system when the program is loaded.
The standard specifies that this must be zeroed before the program
starts. Note that the bss sections and the data sections are
writable, i.e. can be modified.

3) The data section corresponds to the initialized data of your program.

For instance when you write:

int c[] = { 1,2,3};

The sequence of integers 1,2,3 will be stored in the data section.

In short, a C program consists of program instructions, uninitialized
data and initialized data. This logical sections of the program
are mapped into text,bss,and data, respectively.

Other sections may exist, for instance sections containing debug
information, but they are optional.

It is legal to write a program with only the text section, without any
bss/data sections. For instance this program:

int main(int argc,char *argv[])
{
return (argc*argc);
}

has only a text section, and no data/bss section.

Obviously this program could end up having a data/bss section
anyway, since the code that runs before main (the startup code
in a hosted implementation) could need those sections.
jacob
What exactly is a 'bundled image'?

No idea
What exactly is 'microcode'?
Microcode is the software that runs in the CPU itself. Modern
CPUs present a user interface with registers, ALU, etc. Internally
the high level instructions are decomposed into smaller and more
basic instructions. A sequence of them implements the user visible
instructions. This is more hardware related and it is off topic here.
What exactly is 'firmware'?

It is the software supplied by the hardware manufacturer. Again,
this is hardware related and off topic here.

[tele-commuter]

Thanks a lot for the information.

Now let me provide the context.

I work with a network device (a distributed system).

Its a multiple CPU system.The main CPU runs a single monolithic image
(i referred to this as a "bundled image" in my post).

Portions of it get downloaded to other cards in the chassis during
system initialization/bootup.

What I wanted to understand in some detail was how the main CPU gets
this work done
of downloading portions of code onto other cards.I presume this is
related to way the code
is written,how makefiles are written,and how the binary is laid out in
memory to achieve this
functionality etc.

I do understand portions of my queries are off topic but I am trying to
get some clarity on
how much of all this really language/and hence compiler/linker/loader
dependant and also
how these tools come together to achieve some complicated ability like
the context I have
described.

Thanks anyways for all the help.

All the questions I have asked were keeping this situation in mind.

[Flash Gordon]

jacob navia wrote:

tele-commuter a écrit :

Hi folks,

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

What exactly is a linker script?

This is an extension of the GNU linkers that allows
GNU people to configure their linker. Normal users
are not supposed to use that, at least I didn't understand
anything about it. This is GNU specific, so off topic
here.

<OT>
I've used plenty of systems that had absolutely nothing to do with GNU
that used things called linker scripts where the user was *meant* to
write a linker script.

So you are correct that it is off topic, and may well be correct with
reference to GNU (or maybe not, I'm not going to verify either way) but
you are definitely *not* correct in general.
</OT>

I work with a lot of c code on a daily basis but I really
don't understand :

How exactly the sections
like "text,bss,data etc."

This sections map following parts of the language:

<snip>

This is also all highly system specific. I've worked on plenty of
systems that did not have this combination of sections.

You should also have flagged this as off topic.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Flash Gordon]

tele-commuter wrote:

Thanks a lot for the information.
What information? Please provide context so people can see what you are
replying to. For information on how to do this read
http://cfaj.freeshell.org/google/
Now let me provide the context.

I work with a network device (a distributed system).

Its a multiple CPU system.The main CPU runs a single monolithic image
(i referred to this as a "bundled image" in my post).
<snip>
All the questions I have asked were keeping this situation in mind.

Add all the questions you asked were, and still are, OFF TOPIC.

Now, since Google which you are using shows a post before Jacob's
telling you that it is off topic but you are asking again, I'll explain
what that means.

It means you should ask somewhere else. So please find a group dedicated
to your system and ask there, because it is not what is discussed here.
I'm giving you this advice for your own good, because posting here is
unlikely to get you good answers to your questions.

FYI Jacob only usex x86 systems, and mainly Windows at that, so I doubt
that he knows a lot about how MIPS based systems work. Which is not to
say what he said was wrong for MIPS, it might be entirely correct for
all I know, but the MIPS experts won't be correcting any errors he might
have made.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[jacob navia]

Flash Gordon a écrit :

I work with a lot of c code on a daily basis but I really
don't understand :

How exactly the sections
like "text,bss,data etc."

This sections map following parts of the language:

<snip>

This is also all highly system specific. I've worked on plenty of
systems that did not have this combination of sections.

You should also have flagged this as off topic.

No, I do not agree.

C is a low level systems language, and as such, it is important to
be clear of the usage and the works of this mysterious tool called
THE LINKER.

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

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.

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.

But of course we could agree on our disagreement ... :-)

jacob

[Richard Bos]

jacob navia <ja***@jacob.remcomp.fr> wrote:

Flash Gordon a écrit :

How exactly the sections
like "text,bss,data etc."

This sections map following parts of the language:

This is also all highly system specific. I've worked on plenty of
systems that did not have this combination of sections.

You should also have flagged this as off topic.

No, I do not agree.

C is a low level systems language, and as such, it is important to
be clear of the usage and the works of this mysterious tool called
THE LINKER.

IOW, you do not understend the difference between "how a toy compiler
works on a toy OS" and "how a compiler _could_ work anywhere".

A vague understanding of some irrelevant details of a Windows
implementation are of no help when you're trying to compile for, say,
the Mac. On a real system, the linker and the compiler can[1] be
different systems; one could use a variety of compilers with a single
linker, or a single compiler with a variety of linkers. And be none the
wiser about BSS, and no worse off for all that.

Richard

[1] Note: _can_, not _need_ - the opposite may also be true

[Ingo Menger]

jacob navia schrieb:

THE LINKER.

This part of the system is as important as the compiler actually,
but will never explained and never mentioned anywhere.

Not true.
On my system
man 1 ld
tells me a lot about the linker. Likewise,
man 4 a.out
tells me about the executable format and how the OS's loader treats it.

But it is absolutely CERTAIN, that on other systems, the manuals will
tell different things. On some platforms, there is even more than one
executable format.

So, this is absolutely off topic.

[jacob navia]

Richard Bos a écrit :

jacob navia <ja***@jacob.remcomp.fr> wrote:

Flash Gordon a écrit :

> How exactly the sections
> like "text,bss,data etc."

This sections map following parts of the language:

This is also all highly system specific. I've worked on plenty of
systems that did not have this combination of sections.

You should also have flagged this as off topic.
No, I do not agree.

C is a low level systems language, and as such, it is important to
be clear of the usage and the works of this mysterious tool called
THE LINKER.

IOW, you do not understend the difference between "how a toy compiler
works on a toy OS" and "how a compiler _could_ work anywhere".

A vague understanding of some irrelevant details of a Windows
implementation are of no help when you're trying to compile for, say,
the Mac.
The gcc compiler is the compiler under MAC,and I would be surprised
that it wouldn't use the bss/data/and text sections. Really surprised.
On a real system, the linker and the compiler can[1] be different systems; one could use a variety of compilers with a single
linker, or a single compiler with a variety of linkers. And be none the
wiser about BSS, and no worse off for all that.

Richard

[1] Note: _can_, not _need_ - the opposite may also be true

I am speaking about logical sections, that are implicit in
the semantic of the C language.

int a = 488776;

This implies that somewhere in the executable, the data
488776 is stored in the binary representation specific
to the system where the translaion being done

This is the data section.

I will ignore your remarks about "toy compiler" or "toy system".
The system you are working in is obviously THE ONLY TRUE
OPERATING SYSTEM, and surely THE BEST ONE.

[jacob navia]

Ingo Menger a écrit :

jacob navia schrieb:

THE LINKER.

This part of the system is as important as the compiler actually,
but will never explained and never mentioned anywhere.

Not true.
On my system
man 1 ld
tells me a lot about the linker. Likewise,
man 4 a.out
tells me about the executable format and how the OS's loader treats it.

But it is absolutely CERTAIN, that on other systems, the manuals will
tell different things. On some platforms, there is even more than one
executable format.

So, this is absolutely off topic.

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

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.

And I am not speaking about executable formats but about
executable parts in a logical, abstract way.

jacob

[Ingo Menger]

jacob navia schrieb:

int a = 488776;

This implies that somewhere in the executable, the data
488776 is stored in the binary representation specific
to the system where the translaion being done

Not at all. It could also be, that the following code is generated:
clr
inc
inc
inc
.... and so forth 488776 times
store a

[Ingo Menger]

jacob navia schrieb:

Ingo Menger a écrit : I am not speaking about linker options, I am speaking about what the
linker DOES.
ld takes one or more object files or libraries as input and combines
them to produce a single (usually executable) file. In doing so it
resolves references to external symbols, assigns final addresses to
procedures and variables, revises code and data to reflect new
addresses (a process called "relocation"), and updates symbolic debug
information when present in the file.
And I am not speaking about executable formats but about
executable parts in a logical, abstract way.

There is no such thing as an "abstract executable part".

[jacob navia]

Ingo Menger a écrit :

jacob navia schrieb:

int a = 488776;

This implies that somewhere in the executable, the data
488776 is stored in the binary representation specific
to the system where the translaion being done

Not at all. It could also be, that the following code is generated:
clr
inc
inc
inc
.... and so forth 488776 times
store a

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

And what does it when you ask for the address of that integer like
int *p=&a;
???
It is funny the contortions people will propose just to say:

"Jacob is always wrong"...

Imagine 488776 increment intstructions!!!

That system would store each integer in 400MB!

Well...

You are right Ingo :-)

jacob

[Ingo Menger]

jacob navia schrieb:

Ingo Menger a écrit :

jacob navia schrieb:

int a = 488776;

This implies that somewhere in the executable, the data
488776 is stored in the binary representation specific
to the system where the translaion being done

Not at all. It could also be, that the following code is generated:
clr
inc
inc
inc
.... and so forth 488776 times
store a

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

Nobody said that.

And what does it when you ask for the address of that integer like
int *p=&a;
How about
lda a
It is funny the contortions people will propose just to say:

"Jacob is always wrong"...
No, I did not say that.
You said, that code like
int i = 488776;
would imply, that the number 488776 must be stored somehow in the
object file. And I showed you, that this is /not/ implied.
Imagine 488776 increment intstructions!!!
That system would store each integer in 400MB!

This is not the point. The point is that there is an unlimited number
of ways to create a given number in a memory cell. Loading a constant
that is somehow stored in the obejct file is /one possibility/, but the
C standard certainly does not require to implement it this way.
Likewise, as said before, the C standard does not require text or data
or bss segments and it also tells us nothing about "abstract executable
segments".

[CBFalconer]

tele-commuter wrote:

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

What exactly is a linker script?

I work with a lot of c code on a daily basis but I really
don't understand :

How exactly the sections like "text,bss,data etc." work?

What exactly are they?

I believe the linker script describes this layout.

What exactly is a 'bundled image'?
What exactly is 'microcode'?
What exactly is 'firmware'?
.... snip ...
If it helps,my work involves a lot of driver code
in C on systems using MIPS processors.

Your questions have to do with the mechanics of preparing programs,
and not the actual C language. The language itself is the only
topic here, and thus your questions are off-topic. There is no-one
(necessarily) here who knows the right answers, and, more
important, there is no group to criticize and catch wrong answers.
It does no one good to post such possibly wrong and uncriticized
answers, so you are just tempting some to worsen the whole matter.

You should go to some group that deals with your particular system
and ask there. I haven't the foggiest what that is, but I know it
isn't here.

--
"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/>

[tedu]

jacob navia wrote:

C is a low level systems language, and as such, it is important to
be clear of the usage and the works of this mysterious tool called
THE LINKER.

This part of the system is as important as the compiler actually,

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

[jacob navia]

tedu a écrit :

jacob navia wrote:

C is a low level systems language, and as such, it is important to
be clear of the usage and the works of this mysterious tool called
THE LINKER.

This part of the system is as important as the compiler actually,

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

Interesting...

have you tried to load xlisp?

It is a lisp interpreter written in C.

So you would have a lisp interpreter running in a
C interpreter running in java... :-)

[Flash Gordon]

jacob navia wrote:

Richard Bos a écrit :

jacob navia <ja***@jacob.remcomp.fr> wrote:

Flash Gordon a écrit :

>> How exactly the sections
>> like "text,bss,data etc."
>
> This sections map following parts of the language:

This is also all highly system specific. I've worked on plenty of
systems that did not have this combination of sections.

You should also have flagged this as off topic.

No, I do not agree.

C is a low level systems language, and as such, it is important to
be clear of the usage and the works of this mysterious tool called
THE LINKER.

If it is important to know, then how come I have *never* needed to know
when writing applications in C for Linux? To be honest, I don't even
know what the sections are named on Linux, SCO, AIX or Windows yet I
quite happily write C code that runs on all of them.
IOW, you do not understend the difference between "how a toy compiler
works on a toy OS" and "how a compiler _could_ work anywhere".

A vague understanding of some irrelevant details of a Windows
implementation are of no help when you're trying to compile for, say,
the Mac.

The gcc compiler is the compiler under MAC,and I would be surprised
that it wouldn't use the bss/data/and text sections. Really surprised.

Firstly, I know for a *fact* that the section naming conventions are
different for different systems, because when I worked on embedded
systems I did need to know the names so I could tell the linker where to
put things.

On a real system, the linker and the compiler can[1] be
different systems; one could use a variety of compilers with a single
linker, or a single compiler with a variety of linkers. And be none the
wiser about BSS, and no worse off for all that.

Richard

[1] Note: _can_, not _need_ - the opposite may also be true

I am speaking about logical sections, that are implicit in
the semantic of the C language.

int a = 488776;

This implies that somewhere in the executable, the data
488776 is stored in the binary representation specific
to the system where the translaion being done

This is the data section.

It doesn't always work like that. I've worked on systems where you have
one section which contains variable of both static and automatic
duration (the stack is places in the same section). Compiler and linker
between them generate a linked list of initialisations that need to be
done, and the application started code runs along the linked list
reading address, size and initial value information and initialising
things appropriately. That doesn't sound anything like the data/bss
section system you described.

The world is a *lot* more complex than you think, and systems are a
*lot* more diverse.

FYI I just checked an executable on one of my systems, and is has 28
(yes, twenty eight) different sections. On another machine the
equivalent executable had 27 sections, on a third machine 24 sections.
That is just looking at 3 Linux systems on 2 different processors.
I will ignore your remarks about "toy compiler" or "toy system".
The system you are working in is obviously THE ONLY TRUE
OPERATING SYSTEM, and surely THE BEST ONE.

A lot of us work on multiple operating systems and/or implementations
without any OS.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Nelu]

jacob navia wrote:

Interesting...

have you tried to load xlisp?

It is a lisp interpreter written in C.

So you would have a lisp interpreter running in a
C interpreter running in java... :-)

Why not running java in c in java in c? :-)

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)

[jacob navia]

Flash Gordon a écrit :

jacob navia wrote:

C is a low level systems language, and as such, it is important to
be clear of the usage and the works of this mysterious tool called
THE LINKER.

If it is important to know, then how come I have *never* needed to know
when writing applications in C for Linux? To be honest, I don't even
know what the sections are named on Linux, SCO, AIX or Windows yet I
quite happily write C code that runs on all of them.

Sure, why not?

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

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.

IOW, you do not understend the difference between "how a toy compiler
works on a toy OS" and "how a compiler _could_ work anywhere".

A vague understanding of some irrelevant details of a Windows
implementation are of no help when you're trying to compile for, say,
the Mac.

The gcc compiler is the compiler under MAC,and I would be surprised
that it wouldn't use the bss/data/and text sections. Really surprised.

Firstly, I know for a *fact* that the section naming conventions are
different for different systems, because when I worked on embedded
systems I did need to know the names so I could tell the linker where to
put things.

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.

On a real system, the linker and the compiler can[1] be
different systems; one could use a variety of compilers with a single
linker, or a single compiler with a variety of linkers. And be none the
wiser about BSS, and no worse off for all that.

Richard

[1] Note: _can_, not _need_ - the opposite may also be true

I am speaking about logical sections, that are implicit in
the semantic of the C language.

int a = 488776;

This implies that somewhere in the executable, the data
488776 is stored in the binary representation specific
to the system where the translaion being done

This is the data section.

It doesn't always work like that. I've worked on systems where you have
one section which contains variable of both static and automatic
duration (the stack is places in the same section). Compiler and linker
between them generate a linked list of initialisations that need to be
done, and the application started code runs along the linked list
reading address, size and initial value information and initialising
things appropriately. That doesn't sound anything like the data/bss
section system you described.

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?

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".
The world is a *lot* more complex than you think, and systems are a
*lot* more diverse.

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

FYI I just checked an executable on one of my systems, and is has 28
(yes, twenty eight) different sections. On another machine the
equivalent executable had 27 sections, on a third machine 24 sections.
That is just looking at 3 Linux systems on 2 different processors.

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

I will ignore your remarks about "toy compiler" or "toy system".
The system you are working in is obviously THE ONLY TRUE
OPERATING SYSTEM, and surely THE BEST ONE.

A lot of us work on multiple operating systems and/or implementations
without any OS.

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

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.fr> writes:

Flash Gordon a écrit :

I work with a lot of c code on a daily basis but I really
don't understand :

How exactly the sections
like "text,bss,data etc."
This sections map following parts of the language: <snip>
This is also all highly system specific. I've worked on plenty of
systems that did not have this combination of sections.
You should also have flagged this as off topic.

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?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[tedu]

jacob navia wrote:

tedu a écrit :

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

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]

On 2006-01-19, tedu <[e-mail]> wrote:

jacob navia wrote:

C is a low level systems language, and as such, it is important to
be clear of the usage and the works of this mysterious tool called
THE LINKER.

This part of the system is as important as the compiler actually,

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]

jacob navia <ja***@jacob.remcomp.fr> writes:

Flash Gordon a écrit :

jacob navia wrote:

> C is a low level systems language, and as such, it is important to
> be clear of the usage and the works of this mysterious tool called
> THE LINKER. If it is important to know, then how come I have *never* needed to
know when writing applications in C for Linux? To be honest, I don't
even know what the sections are named on Linux, SCO, AIX or Windows
yet I quite happily write C code that runs on all of them.

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.

[...]

It doesn't always work like that. I've worked on systems where you
have one section which contains variable of both static and
automatic duration (the stack is places in the same
section). Compiler and linker between them generate a linked list of
initialisations that need to be done, and the application started
code runs along the linked list reading address, size and initial
value information and initialising things appropriately. That
doesn't sound anything like the data/bss section system you
described.

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Flash Gordon]

jacob navia wrote:

Flash Gordon a écrit :

jacob navia wrote:

>
> C is a low level systems language, and as such, it is important to
> be clear of the usage and the works of this mysterious tool called
> THE LINKER.
If it is important to know, then how come I have *never* needed to
know when writing applications in C for Linux? To be honest, I don't
even know what the sections are named on Linux, SCO, AIX or Windows
yet I quite happily write C code that runs on all of them.

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.

IOW, you do not understend the difference between "how a toy compiler
works on a toy OS" and "how a compiler _could_ work anywhere".

A vague understanding of some irrelevant details of a Windows
implementation are of no help when you're trying to compile for, say,
the Mac.

The gcc compiler is the compiler under MAC,and I would be surprised
that it wouldn't use the bss/data/and text sections. Really surprised.

Firstly, I know for a *fact* that the section naming conventions are
different for different systems, because when I worked on embedded
systems I did need to know the names so I could tell the linker where
to put things.

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.

<snip>

It doesn't always work like that. I've worked on systems where you
have one section which contains variable of both static and automatic
duration (the stack is places in the same section). Compiler and
linker between them generate a linked list of initialisations that
need to be done, and the application started code runs along the
linked list reading address, size and initial value information and
initialising things appropriately. That doesn't sound anything like
the data/bss section system you described.

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.

The world is a *lot* more complex than you think, and systems are a
*lot* more diverse.

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.

FYI I just checked an executable on one of my systems, and is has 28
(yes, twenty eight) different sections. On another machine the
equivalent executable had 27 sections, on a third machine 24 sections.
That is just looking at 3 Linux systems on 2 different processors.

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.

I will ignore your remarks about "toy compiler" or "toy system".
The system you are working in is obviously THE ONLY TRUE
OPERATING SYSTEM, and surely THE BEST ONE.

A lot of us work on multiple operating systems and/or implementations
without any OS.

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.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[CBFalconer]

jacob navia wrote:

Flash Gordon a écrit :

.... massive snippage ...

If it is important to know, then how come I have *never* needed
to know when writing applications in C for Linux? To be honest,
I don't even know what the sections are named on Linux, SCO, AIX
or Windows yet I quite happily write C code that runs on all of
them.

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]

In article <43**********************@news.wanadoo.fr> jacob navia <ja***@jacob.remcomp.fr> writes:
....

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, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Dik T. Winter]

In article <43***********************@news.wanadoo.fr> jacob navia <ja***@jacob.remcomp.fr> writes:

Ingo Menger a écrit :

jacob navia schrieb:

int a = 488776;

This implies that somewhere in the executable, the data
488776 is stored in the binary representation specific
to the system where the translaion being done

Why?
Not at all. It could also be, that the following code is generated:
clr
inc
inc
inc
.... and so forth 488776 times
store a
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.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

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

--
A+

Emmanuel Delahaye