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,d ata 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(intern et 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,d ata 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,d ata 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,d ata 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.re mcomp.fr> wrote:

Flash Gordon a écrit :

How exactly the sections
like "text,bss,d ata 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.re mcomp.fr> wrote:

Flash Gordon a écrit :

> How exactly the sections
> like "text,bss,d ata 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.