Quote:
Originally Posted by aagajaba
I came 2 know 1 important thing.
195 is opcode for return in Pentium processors.
So it works with pentium.
But in core 2 duo, (as is mine), before returning from a function, it seems it is necessary to have an instruction called leave. I am not usre about this though.
So it gives segfault in core 2 duo.  |
Works fine on mine.
Code:
[05:36:05][aconole@ssh:~]
$ cat /proc/cpuinfo | grep Dual
model name : Intel(R) Pentium(R) Dual CPU E2200 @ 2.20GHz
model name : Intel(R) Pentium(R) Dual CPU E2200 @ 2.20GHz
[05:36:10][aconole@ssh:~]
$ cat test.cpp
#include <iostream>
using namespace std;
int main = ( cout << "Hello world!\n", 195 );
[05:36:13][aconole@ssh:~]
$ g++ -o tst test.cpp
[05:36:18][aconole@ssh:~]
$ ./tst
Hello world!
[05:36:19][aconole@ssh:~]
$
Just as an fyi.
A good way to see what's happening is to break at the cout print. The way I did this was make the code looks as follows:
Code:
#include <iostream>
using namespace std;
void pwn(const char *p){cout << p;}
int main = ( pwn("hello world\n"), 195 );
Then break on pwn.
Following is the backtrace:
Code:
#0 0x00000000004007d0 in pwn(char*) ()
#1 0x000000000040082d in __static_initialization_and_destruction_0(int, int)
()
#2 0x000000000040084c in global constructors keyed to _Z3pwnPc ()
#3 0x0000000000400916 in __do_global_ctors_aux ()
#4 0x000000000040066b in _init ()
#5 0x00007fffffffde18 in ?? ()
#6 0x00000000004008a5 in __libc_csu_init (argc=4196668, argv=0x1, envp=0x0)
at elf-init.c:79
#7 0x00007ffff732b512 in __libc_start_main () from /lib64/libc.so.6
#8 0x0000000000400709 in _start () at ../sysdeps/x86_64/elf/start.S:113
That ?? () function call looks a little suspicious can be found in the memory map at:
Code:
7ffffffea000-7ffffffff000 rw-p 7ffffffea000 00:00 0 [stack]
My guess is that it's related to the way the linker sets up the initialization process. I don't know that there's any "rule" that a program needs a main function, and this would certainly be a creative use of the main variable as a way to satisfy a braindead link check (omg - no main symbol?!) while not requiring main to actually do anything. Try setting a breakpoint on the address of main - it's never actually hit. However, my guess is that this is compiler dependent behavior. Not something to rely on, but certainly funny. The 195, if it's truly a return op code, is probably there for those versions of the compiler which will execute &main.
All in all, neat piece of code.
