c program binary/image in memory

[CBFalconer]

Re: c program binary/image in memory

tele-commuter wrote:[color=blue]
>
> 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'?
>[/color]
.... snip ...[color=blue]
>
> If it helps,my work involves a lot of driver code
> in C on systems using MIPS processors.[/color]

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.c om, 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]

Re: c program binary/image in memory

jacob navia wrote:[color=blue]
> 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,[/color]

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

[jacob navia]

Re: c program binary/image in memory

tedu a écrit :[color=blue]
> jacob navia wrote:
>[color=green]
>>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,[/color]
>
>
> i did some of my C programming in a C interpreter written in java.
> understanding the mysterious linker was a non-issue.
>[/color]
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]

Re: c program binary/image in memory

jacob navia wrote:[color=blue]
> Richard Bos a écrit :[color=green]
>> jacob navia <jacob@jacob.re mcomp.fr> wrote:
>>[color=darkred]
>>> 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.[/color][/color][/color]

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.
[color=blue][color=green]
>> IOW, you do not understend the difference between "how a toy compiler
>> works on a toy OS" and "how a compiler _could_ work anywhere".[/color]
>[color=green]
>> 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.[/color]
>
> 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.[/color]

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.
[color=blue][color=green]
>> 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[/color]
>
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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]

Re: c program binary/image in memory

jacob navia wrote:[color=blue]
> 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... :-)[/color]
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]

Re: c program binary/image in memory

Flash Gordon a écrit :[color=blue]
> jacob navia wrote:
>[color=green][color=darkred]
>>>>
>>>> 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.[/color][/color]
>
>
> 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.
>[/color]

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.
[color=blue][color=green][color=darkred]
>>> IOW, you do not understend the difference between "how a toy compiler
>>> works on a toy OS" and "how a compiler _could_ work anywhere".[/color]
>>
>>[color=darkred]
>>> 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.[/color]
>>
>>
>> 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.[/color]
>
>
> 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.
>[/color]

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.
[color=blue][color=green][color=darkred]
>>> 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[/color]
>>
>>
>> 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.[/color]
>
>
> 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.[/color]

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

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

[color=blue]
> 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.
>[/color]

As I said in my previous message (and repeat now) the 3 sections
I mentioned are only the MINIMAL ones!
[color=blue][color=green]
>> 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.[/color]
>
>
> A lot of us work on multiple operating systems and/or implementations
> without any OS.[/color]

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

[Keith Thompson]

Re: c program binary/image in memory

jacob navia <jacob@jacob.re mcomp.fr> writes:[color=blue]
> Flash Gordon a écrit :[color=green][color=darkred]
>>>> 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:[/color]
>> <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.[/color]
>
> No, I do not agree.
>
> C is a low level systems language,[/color]

Agreed, mostly.
[color=blue]
> and as such, it is important to
> be clear of the usage and the works of this mysterious tool called
> THE LINKER.[/color]

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.
[color=blue]
> 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).[/color]

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.
[color=blue]
> 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.[/color]

What is a "section"? Please answer based on references to the C
standard, not on your knowledge of MS Windows on x86-based systems.
[color=blue]
> 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.[/color]

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_Keit h) kst-u@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]

Re: c program binary/image in memory

jacob navia wrote:[color=blue]
> tedu a écrit :[color=green]
> > i did some of my C programming in a C interpreter written in java.
> > understanding the mysterious linker was a non-issue.[/color]
>
> have you tried to load xlisp?
>
> It is a lisp interpreter written in C.[/color]

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]

Re: c program binary/image in memory

On 2006-01-19, tedu <tu@zeitbombe.o rg> wrote:[color=blue]
> jacob navia wrote:[color=green]
>> 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,[/color]
>
> i did some of my C programming in a C interpreter written in java.
> understanding the mysterious linker was a non-issue.[/color]

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]

Re: c program binary/image in memory

jacob navia <jacob@jacob.re mcomp.fr> writes:[color=blue]
> Flash Gordon a écrit :[color=green]
>> jacob navia wrote:[color=darkred]
>>>>> 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.[/color]
>> 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.[/color]
>
> Sure, why not?
>
> But when ASKED (as the original poster asked) why not learn?[/color]

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.
[color=blue]
> 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.[/color]

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.

[...]
[color=blue][color=green]
>> 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.[/color]
>
> 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?[/color]

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_Keit h) kst-u@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]

Re: c program binary/image in memory

jacob navia wrote:[color=blue]
> Flash Gordon a écrit :[color=green]
>> jacob navia wrote:
>>[color=darkred]
>>>>>
>>>>> 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.[/color]
>>
>> 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.[/color]
>
> Sure, why not?
>
> But when ASKED (as the original poster asked) why not learn?[/color]

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.
[color=blue]
> 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.[/color]

Which does not make it topical here.
[color=blue][color=green][color=darkred]
>>>> 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.[/color]
>>
>> 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.[/color]
>
> 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.[/color]

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>
[color=blue][color=green]
>> 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.[/color]
>
> 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?[/color]

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.
[color=blue]
> 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".[/color]

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.
[color=blue][color=green]
>> The world is a *lot* more complex than you think, and systems are a
>> *lot* more diverse.[/color]
>
> 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! :-)[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
> As I said in my previous message (and repeat now) the 3 sections
> I mentioned are only the MINIMAL ones![/color]

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.
[color=blue][color=green][color=darkred]
>>> 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.[/color]
>>
>> A lot of us work on multiple operating systems and/or implementations
>> without any OS.[/color]
>
> Yes, then it is the program that replaces the OS, and this
> distinction blurrs somehow.[/color]

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]

Re: c program binary/image in memory

jacob navia wrote:[color=blue]
> Flash Gordon a écrit :
>[/color]
.... massive snippage ...[color=blue][color=green]
>>
>> 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.[/color]
>
> Sure, why not?
>
> But when ASKED (as the original poster asked) why not learn?[/color]

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.c om, 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]

Re: c program binary/image in memory

In article <43cfb413$0$666 0$8fcfb975@news .wanadoo.fr> jacob navia <jacob@jacob.re mcomp.fr> writes:
....[color=blue]
> I am not speaking about linker options, I am speaking about what the
> linker DOES.[/color]

O. What does the linker do?
[color=blue]
> 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.[/color]

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, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Dik T. Winter]

Re: c program binary/image in memory

In article <43cfc188$0$213 06$8fcfb975@new s.wanadoo.fr> jacob navia <jacob@jacob.re mcomp.fr> writes:[color=blue]
> Ingo Menger a écrit :[color=green]
> > jacob navia schrieb:[color=darkred]
> >>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[/color][/color][/color]

Why?
[color=blue][color=green]
> > Not at all. It could also be, that the following code is generated:
> > clr
> > inc
> > inc
> > inc
> > .... and so forth 488776 times
> > store a[/color]
>
> And it does that each time you access that variable... How clever[/color]

Why? The constant 488776 is used only once in your program, on
initialization of 'a'.
[color=blue]
> And what does it when you ask for the address of that integer like
> int *p=&a;
> ???[/color]

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, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Emmanuel Delahaye]

Re: c program binary/image in memory

tele-commuter a écrit :[color=blue]
> I want to understand how exactly is an image(compiled
> c code and loaded into memory) stored in memory.[/color]

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.
[color=blue]
> What exactly is a linker script?[/color]

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

--
A+

Emmanuel Delahaye