C++ source code compilation

[Rui Maciel]

I think I know what happened here. When someone said that an object file
contains compiled machined code, you erroneously thought that he meant
that an object file is directly executable as-is. Thus in your typical
sociopath manner you loudly and proudly objected to the notion.

The problem isn't quite that. The expression "object file" doesn't refer to
the same concept as "object code", and the comparison is supposed to be
between "machine code" and "object code", not between "machine code" and
"object file". The "object file" concept has been introduced to this
discussion as a strawman, and therefore it doesn't make sense to draw any
conclusion regarding how "object code" and "machine code" are supposed to be
two different things by comparing "object files" to "machine code". It
would be like arguing that "figures" and "images" are two different things,
and then proceeding to discuss how the PNG file format stores information
which doesn't form part of a figure, and therefore that meant that figures
and images aren't the same thing. And this would be silly.


Rui Maciel

 

[Juha Nieminen]

A compiler directly outputs objects files and object files typically
contain relocatable machine code ergo compilers typically directly
output machine code.

Simple. Logic.

He is confusing "machine code" with "executable file". He thought that
the original claim is "the compiler creates an executable file directly"
rather than "the compiler creates machine code".

Now he is trying to desperately pretend that "machine code" means
"executable file" rather than what it really mens.

Of course, as said, even executable files (eg. Windows .exe files)
cannot be executed raw. They have to be loaded with a dynamic linker
that performs further modifications to the binary before it can be
properly executed. (Among other things, the dynamic linker may rebase
the code to use a different base address, as well as setting up the
addresses of shared system library functions.)

 

[Juha Nieminen]

If a newgroup post contains C++ code , do you call that message a C++ code
file? No!
If a file has a section that contains some machine code, this doesn't
neccessarily make that file machine code.

Stop pretending. Just admit that you confused "machine code" with
"executable file". Stop digging the hole deeper.

 

[ralph]

It's very difficult at best. It's hard to even distinguish code from
data. Consider the following x86 sequence:

mov eax, offset str
calll xyz
jmp abc
str db "this an inline string"

How does the disassembler know the 0x74, 0x68, 0x69, 0x73... is code
or data? It certainly *appears* to start with a JZ instruction.

context

-ralph

 

[Ian Collins]

Stop pretending. Just admit that you confused "machine code" with
"executable file". Stop digging the hole deeper.

You know he can't stop!

 

[Ian Collins]

Oh so you were not admitting your mistake after all; oh well, not too
surprising considering that you are so dense that you have your own
event horizon.

Ask him how "object code" gets converted to "machine code". That should
provide some more amusement.

 

[88888 Dihedral]

Ask him how "object code" gets converted to "machine code". That should
provide some more amusement.

A real machine and a virtual machine are different.

I don't like static bound libs in unix. Dynamical linked libraries eat memory
slowly than static bound ones.

 

[ralph]

And just what context is it that separates the two? Once an
executable, this is basically a string of bytes. IOW, the 0x74,
0x68... immediate follows the bytes of the jmp abc. And it looks like
code on top of it.

Perhaps eax is actually a code pointer being passed to xyz. Or
perhaps it's a pointer to a string. You can't generally tell from the
object.

While disassemblers use may heuristics to try and establish the
separation between code and data, they almost always need human help
in an iterative process to do a decent job.

Ahhh, now I understand.

When did I ever suggest otherwise? <g>

-ralph

 

[Juha Nieminen]

How exactly do you run this object file if it is trully machine code?
Are you suggesting its machine code but it cannot be run on any single
machine on the planet?

I find it amusing that time and again you are confirming that you
mistook "machine code" for "an executable file", but rather than simply
admitting the mistake, you keep insisting that your definition of
"machine code" must be correct.

Please explain to me how "object code" differs from "machine code".

Your answer seems to be: "Machine code can be run directly." Except
that executable files (such as .exe files in Windows) cannot be run
directly. They require a dynamic linker that loads the contents of the
executable into memory and performs some changes to it (such as rebasing
all absolute jumps and setting up system function call addresses) before
they can be run by the CPU.

In principle there's no reason why an object file could not be run
directly by using a similar dynamic linker (as long a s the object file
is not dependent on other object files). In fact, dynamically loadable
libraries, which are basically special object files, *can* be run
directly in most operating systems without an actual literal executable
file, by using the same dynamic linker. That's because executables, object
files and dynamically loadable libraries all contain executable machine
code that only requires linking (static or dynamic) to set up all the
absolute memory addresses.

The closest thing to a pure executable file that does not require any
form of dynamic linking and that is purely a "load-and-run" file is an
old .com file in MS-DOS. These files do indeed contain *nothing* else
than pure machine code from beginning to end (unlike eg. .exe files or
any other executable file in basically any desktop OS, which contain
lots of non-machine-code for the dynamic linker, such as relocation data).

 

[Juha Nieminen]

That's absolute bullshit.
You said that the compiler directly outputs machine code.
Now you are saying well it doens't really output machine code it ouptputs
soemthing else that contains machine code.

You have still not told us what is, in your opinion, "machine code".
Please enlighten us.

 

[Jorgen Grahn]

Thanks for the warning (new here)

Well, check for yourself and make up your own mind. Leigh Johnston and
Paul have fought a public battle here for at least a year. I have them
both killfiled at the moment.

/Jorgen

 

[Juha Nieminen]

No thanks, you seem very confused <snip>

Just as I thought. You know that you are spouting bullshit, but you
just can't stop and admit you were mistaken.

(The reason why you refuse to explain what you mean is that you realize
that an executable file is not all that different from an object file.
It cannot be run as-is, but needs modifications (by a dynamic linker)
before it can be executed. However, you just can't admit this. Instead,
you must dig a deeper hole for yourself. You can't stop.)

 

[Juha Nieminen]

I have made it clear what machine code is on many occassions.
It is code that can be read by a machine.
Thats not my opinion, its a fact.

So what's the difference between an object file and an .exe file
(so that the former is not "machine code" but the latter is)?

Please stop fishing for something to trip me up with you dimwitted
pigfucker.

Maybe you'll learn how to interact with people properly some day. Perhaps
in 5 to 10 years.

 

[Juha Nieminen]

My definition of machine code is code that runs on a machine.
An object file, that requires further translation before being read by a
machine, is not machine code.
How can you call something machine code when it's not code that can be run
on a machine?

So an .exe file isn't "machine code" either (because it cannot be run
as-is, but requires further modifications before it can be run). Thus, by
your own very definition a linker does not produce "machine code", which
is opposite of what you said originally.

Of course *your* definition of "machine code" (which you came up with
only because you cannot admit a mistake) is rather different than what the
rest of the world defines as "machine code". Your definition seems to be
"an executable file that requires no further modifications before it can
be run on a CPU". I suppose DOS .com files meet those requirements. Of
course those haven't been used in a long time.

The rest of the world does not define "machine code" as a file format.
"Machine code" has nothing to do with files. They refer to data that are
direct CPU opcodes (regardless of where that data might be stored).

 

[Juha Nieminen]

You have been proven to be a complete fool, once again. And yet you do not
even have the dignity to accept you errors and admit

Btw, this is a classic example of psychological projection.

http://en.wikipedia.org/wiki/Psychological_projection

 

[Juha Nieminen]

The linker creates machine code.

Aha, gotcha.

By your own definition a linker does *not* produce "machine code".

Why? Because your own definition was "machine code is a file that can
be run without modification". A linker will produce eg. an .exe file on
Windows, which can *not* be run without modification. The same is true
in linux and other unix systems (where the executable file will be in
COFF or ELF format, both similar to .exe in that they require modification
before they can be run).

Please claim that I'm wrong.

 

[Dombo]

Op 08-Dec-11 3:52, John Bokma schreef:

Thanks for the warning (new here)

When someone resorts to profanity and personal attacks you can be pretty
sure that person has run out of arguments to support their position but
is not man enough to admit he's wrong. Some people reach that point very
quickly.

The signal to noise ratio of this newsgroup improves significantly if
you killfile Paul and those who feel compelled to reply to his postings
(Leigh Johnston, Juha Nieminen).

 

[88888 Dihedral]

You said....... "I suspect very few modern C++ compilers produce C as an
intermediate but rather create machine code directly".
A C++ compiler does not create machine code , it creates and object file.
The linker creates machine code.

You said the compiler outputs machine code and now you are trying so say it
outputs something that CONTAINS machine code. Why is everything you say you
twisted and incorrect?

A human can fake to be wrong in writing.
How about a robot?

 

[Paul N]

Object files do not contain machine code.
* Shakes head in disbelief*

I was under the impression that object files contained machine code
for the bits that could be compiled, plus information as to how things
can be linked together.

To test this, I compiled the following snippet:

int sub(int i);

int main(void) {
int i;
for (i = 0; i < 3; i++) sub(i);
return 0;
}

The .OBJ file contains the following:

00D0 : EB 06 56 E8 00 00 59 46-83 FE 03 7C F5 33 C0 EB

Which after running through a disassembler is:

1544:01D2 56 PUSH SI
1544:01D3 E80000 CALL 01D6
1544:01D6 59 POP CX
1544:01D7 46 INC SI
1544:01D8 83FE03 CMP SI,+03
1544:01DB 7CF5 JL 01D2

Looks like machine code to me - just needs the correct call address
filling in.

 

[88888 Dihedral]

I was under the impression that object files contained machine code
for the bits that could be compiled, plus information as to how things
can be linked together.

To test this, I compiled the following snippet:

int sub(int i);

int main(void) {
int i;
for (i = 0; i < 3; i++) sub(i);
return 0;
}

The .OBJ file contains the following:

00D0 : EB 06 56 E8 00 00 59 46-83 FE 03 7C F5 33 C0 EB

Which after running through a disassembler is:
ADDRESS: segmentffset
1544:01D2 56 PUSH SI
1544:01D3 E80000 CALL 01D6
1544:01D6 59 POP CX

loop index in SI or CX ?