RIP :(

oh man, hab mir gerade mal das dissasembly von meinem programm reingezogen schöne scheiße...

0000000000025520 <blabla>:
   25538:	ff 35 7a 03 23 00    	pushq  0x23037a([b]%rip[/b])        # 2558b8 <_GLOBAL_OFFSET_TABLE_+0x8>
   2553e:	ff 25 7c 03 23 00    	jmpq   *0x23037c(%rip)        # 2558c0 <_GLOBAL_OFFSET_TABLE_+0x10>
   25544:	0f 1f 40 00          	nopl   0x0(%rax)

kann mir einer sagen warum eine

size_t xxx(){ return 5; }

mit -O2 oder -O3 nicht geinlined wird

muss ich jetzt alles neu machen

es heißt disassembly...

und diese ganzen %rip im code gefallen mir auch nicht, wie bekomm ich die raus

*rant*

+live schrieb:

und diese ganzen %rip im code gefallen mir auch nicht, wie bekomm ich die raus

-mcmodel=large . Warum ist das für dich schlimm? Oder möchtest du einfach den Assembly Code verstehen lernen? Dann kann ich dich verstehen. RIP Relative Addressing ist sehr unleserlich für einen Menschen

Wegen dem Inlining: Fällt mir spontan nichts ein.

MfG

cooky451

oO schrieb:

size_t xxx(){ return 5; }
mit -O2 oder -O3 nicht geinlined wird

Sollte eigentlich, irgendwie. Zeig mal ein kompilierbares Beispiel, bei dem es nicht geinlined wird.

hustbaer

/rant/ schrieb:

Dann kann ich dich verstehen. RIP Relative Addressing ist sehr unleserlich für einen Menschen

Es gibt auch leserliche Schreibweisen für IP-relative Adressierung, siehe 68K Assembler.

cooky451 schrieb:

oO schrieb:
size_t xxx(){ return 5; }
mit -O2 oder -O3 nicht geinlined wird
Sollte eigentlich, irgendwie. Zeig mal ein kompilierbares Beispiel, bei dem es nicht geinlined wird.

#include <stdio.h>

size_t x(){
	return 1;
}

size_t y(){
	return 2 + x();
}

int main(){
	printf("%d",y());
	return 0;
}

compiliert mit 'gcc -O3 -fPIC main.c'

0000000000400500 <y>:
  400500:	48 83 ec 08          	sub    $0x8,%rsp
  400504:	31 c0                	xor    %eax,%eax
  400506:	e8 e5 ff ff ff       	callq  4004f0 <x>
  40050b:	48 83 c4 08          	add    $0x8,%rsp
  40050f:	48 83 c0 02          	add    $0x2,%rax
  400513:	c3                   	retq   
  400514:	66 66 66 2e 0f 1f 84 	nopw   %cs:0x0(%rax,%rax,1)
  40051b:	00 00 00 00 00

compiliert mit 'gcc -O3 main.c'

0000000000400500 <y>:
  400500:	b8 03 00 00 00       	mov    $0x3,%eax
  400505:	c3                   	retq   
  400506:	66 2e 0f 1f 84 00 00 	nopw   %cs:0x0(%rax,%rax,1)
  40050d:	00 00 00

da es aber eine lib ist, muss ich die doch mit -fPIC bauen, oder

/rant/ schrieb:

Oder möchtest du einfach den Assembly Code verstehen lernen?

nö, hatte eine alte version die mir vom softwaredesign nicht gefallen hat. dann hab ich es redesigned (trennung in libraries und compile units) und war iwie langsamer. und unabhängig von der neuen architektur hätt ich mir keinen so großen einbruch erwartet. was jetzt natürlich schlecht ist, da mir die zeit für einen erneuten umbau fehlt (und eig. will ich das auch nicht, vllt. muss ich ja doch iwann mal wieder an den code...)

aber ich kann es jetzt auch nicht ändern, volkard hat mal was angedeutet, dass der neue gcc funktionen anbietet (iwas von -fwhole-program -fdata-sections -ffunction-sections) war da mal die rede, der wird aber noch nicht mit debian ausgeliefert und separat installieren will ich die neue version deswegen auch nicht.

und dann ist mir gestern auch noch aufgefallen, dass ich langsam graue haare bekomm und zum alteisen komm - alles in allem also ein super tag

cooky451

Eine Library mit main Funktion?

oO schrieb:

cooky451 schrieb:

oO schrieb:
size_t xxx(){ return 5; }
mit -O2 oder -O3 nicht geinlined wird
Sollte eigentlich, irgendwie. Zeig mal ein kompilierbares Beispiel, bei dem es nicht geinlined wird.

#include <stdio.h>

size_t x(){
	return 1;
}

size_t y(){
	return 2 + x();
}

int main(){
	printf("%d",y());
	return 0;
}

compiliert mit 'gcc -O3 -fPIC main.c'

0000000000400500 <y>:
  400500:	48 83 ec 08          	sub    $0x8,%rsp
  400504:	31 c0                	xor    %eax,%eax
  400506:	e8 e5 ff ff ff       	callq  4004f0 <x>
  40050b:	48 83 c4 08          	add    $0x8,%rsp
  40050f:	48 83 c0 02          	add    $0x2,%rax
  400513:	c3                   	retq   
  400514:	66 66 66 2e 0f 1f 84 	nopw   %cs:0x0(%rax,%rax,1)
  40051b:	00 00 00 00 00

compiliert mit 'gcc -O3 main.c'

0000000000400500 <y>:
  400500:	b8 03 00 00 00       	mov    $0x3,%eax
  400505:	c3                   	retq   
  400506:	66 2e 0f 1f 84 00 00 	nopw   %cs:0x0(%rax,%rax,1)
  40050d:	00 00 00

da es aber eine lib ist, muss ich die doch mit -fPIC bauen, oder

Das liegt wohl an dem fehlenden static in den Funktionsprototypen. So muss der Compiler ja davon ausgehen, dass die Funktion aus anderen Modulen aufgerufen werden könnte.

Shade Of Mine

Mein i686-apple-darwin10-gcc-4.2.1 optimiert den Aufruf von x und y weg.

Tippgeber schrieb:

Das liegt wohl an dem fehlenden static in den Funktionsprototypen. So muss der Compiler ja davon ausgehen, dass die Funktion aus anderen Modulen aufgerufen werden könnte.

wird sie ja auch... aber ich dachte man kann sie trotzdem inlinen, zumindest innerhalb der library

Shade Of Mine schrieb:

Mein i686-apple-darwin10-gcc-4.2.1 optimiert den Aufruf von x und y weg.

auch mit -fPIC das wär ja end geil

also ich hab grad den am start... gcc (Debian 4.4.5-8) 4.4.5

oO schrieb:

Tippgeber schrieb:

Das liegt wohl an dem fehlenden static in den Funktionsprototypen. So muss der Compiler ja davon ausgehen, dass die Funktion aus anderen Modulen aufgerufen werden könnte.

wird sie ja auch... aber ich dachte man kann sie trotzdem inlinen, zumindest innerhalb der library

sry. meinte compile unit, library sollte eig. erst ab gcc 4.5 mögl. sein - so der plan...

aber wenn das mit -fPIC nicht geht, kann ichs eh vergessen ausser ich mach wieder wie früher ein riesenbaby

auch mit -fPIC das wär ja end geil

und was hat das mit inlining zu tun?

piepic schrieb:

auch mit -fPIC das wär ja end geil

und was hat das mit inlining zu tun?

sind hier nur noch deppen

Shade Of Mine

oO schrieb:

Shade Of Mine schrieb:

Mein i686-apple-darwin10-gcc-4.2.1 optimiert den Aufruf von x und y weg.

auch mit -fPIC das wär ja end geil

Ja.
sowohol bei

gcc -fPIC -O3 -c test.c -S

als auch

gcc -fpic -O3 -c test.c -S

kommt das als Ergebnis:

_main:
LFB5:
	pushq	%rbp
LCFI4:
	movq	%rsp, %rbp
LCFI5:
	movl	$3, %esi
	leaq	LC0(%rip), %rdi
	xorl	%eax, %eax
	call	_printf
	xorl	%eax, %eax
	leave
	ret

$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

gut zu wissen, dann wirds auf nem mac signifikant schneller laufen als unter linux

was mich aber ein bischen wundert, weil es die augenscheinlich neuere version unter linux nicht gebacken bekommt... oder geht es bei anderen und nur bei mir nicht

also bei mir geht es einfach nicht...

main:
.LFB13:
	.cfi_startproc
	subq	$8, %rsp
	.cfi_def_cfa_offset 16
	xorl	%eax, %eax
	call	y@PLT
	leaq	.LC0(%rip), %rdi
	movq	%rax, %rsi
	xorl	%eax, %eax
	call	printf@PLT
	xorl	%eax, %eax
	addq	$8, %rsp
	ret

wenn die funktion static ist, dann schon:

main:
.LFB13:
	.cfi_startproc
	leaq	.LC0(%rip), %rdi
	subq	$8, %rsp
	.cfi_def_cfa_offset 16
	movl	$3, %esi
	xorl	%eax, %eax
	call	printf@PLT
	xorl	%eax, %eax
	addq	$8, %rsp
	ret
	.cfi_endproc

aber wie gesagt, das bringt mich nicht weiter, weil dann kann ich gleich den ganzen library käse weglassen