Dat zijn segment registers en worden alleen gebruikt in 16bit code. Linux is volledig 32bit.

http://en.wikipedia.org/wiki/16-bit_x86_assembly_programming
http://my.execpc.com/~geezer/johnfine/segments.htm

Dat heeft er niets mee te maken. En het is Suse linux..

Ah ok thx, maar kunnen 32bit registers wel uitgelezen worden? Zoals
variablen als bijvoorbeeld char name[5]; of int x = 10; ?.

De relatie tussen een register en een variabele hangt geheel
af van het OS. Sommige OS'en willen de argumenten van een
functie in registers hebben anderen, zoals linux, stopt de
argumenten van een functie op de stack. Dus wat wil je nu
weten? Wat de inhoud van een register is of de inhoud van
een variabele?

Nou bevoorbeeld wanneer je iets declareerd van char name[5] = "klaas".
Wat eigenlijk gebeurd in de assembly syntax wanneer je char aanroept.

Want GDB geeft wel veel weer met functies enzo. Maar bv name[5] kan ik
nergens terug vinden. Maar de declaratie van klaas weer wel.

Dat is ten dele juist. Bij libraries is het in elk geval zo dat het volstrekt duidelijk moet zijn waar en in welke volgorde je als caller de parameters opslaat, zodat de 'callee' (de aangeroepen functie) ze kan vinden. Die afspraak is inderdaad OS-afhankelijk. Bijv. Microsoft's Win 3.1 API hanteerde de "Pascal" parameter volgorde die precies andersom is als C-compilers normaal gesproken zouden aanhouden.

Zowel MS als GCC kunnen het Intel 'fastcall' attribuut gebruiken; in dat geval worden de eerste twee (32bit) parameters via ECX en EDX overgedragen, de rest via de stack, zie [url=http://en.wikipedia.org/wiki/X86_calling_conventions#fastcall]Wikipedia[/url].

Daarmee is het naast OS-afhankelijk, ook compiler- en CPU-afhankelijk. Door allerlei (meestal instelbare) compiler optimalisaties kan de compiler voor allerlei constructies kiezen, en is daar in het geval van lokale functies (in je eigen code dus, zeg maar in 1 sourcefile) nog veel vrijer in. Een functie kan zelfs geheel 'verdwijnen' doordat de code 'inline' wordt tussengevoegd; GCC kan dat bijv. met memcpy doen.

Zomaar 2 pages met info over compiler optimizations: [url=http://www.linuxjournal.com/article/7269]GCC[/url] en [url=http://www.tantalon.com/pete/cppopt/compiler.htm]MS Visual C++ 6.0[/url]

Helemaal correct, het mijne was wat kort door de bocht. Maar
gezien de vraag denk ik dat de OP nog een lange weg te gaan
heeft ;)

Dus als ik het goed begrijp heeft de compiler veel invloed op de toewijzing
van de variablen op de stack?

Want stel je neem bv char name[5] = "Klaas";. Pushed dan de compiler char name[5] = "klaas"; in z'n geheel op de stack. Of word nog verdeeld bv char dan name dan de bites voor name en dan de string klaasje.

Meestal wordt alleen een pointer naar de string op de stack
gepushed.

Ik was al bezig met zoeken na die pointer trouwens maar was opgevement
de draad kwijt. Was zo ver gekomen dat hetwel duidelijk is wat er gebeurd
met printf onder assembly.

push 0x804845b
call 0x8048268 (printf)

Bij het commando x/s 0x804845b gaf die weer:

0x80485b (_IO_stdin_used +11): "%sn";

Dat had ik ook gedeclared in printf("%sn",msg); Maar msg kan ik nergens
terug vinden.

Staat klaasje dan alleen maar in de pointer ?

Want waneer je onder GDB disas 0x8048268 zegt ie:

0x80486268 (printf): jmp *0x80955c
0x8048626e (printf+6): push $0x8
0x80486273 (printf+11): jmp 0x8048148 <_init+24);

Nu lijkt het erop dat die 8 bytes gerserveerd voor klaasje. Maar 0x80955c
verwijs na _global_offset_table_16 en niet na msg. Ook inet_24 niet want
dat adress van 0x8048148 verwijs na een string met iets als "y5[25504
bij%T25504b"

Ps. Heb het al gevonden. Met disals 0x804845b wat %sn was geeft die nu aan:
0x8048450 (_IO_stdin_used) add eax,(eax)
0x8048452 (_IO_stdin_used+2) add (eax),al
0x8048454 (_IO_stdin_used+4) push $0x6f6c6c65
0x8048459 (_IO_stdin_used+9) and eax,(eax)
0x804845b (_IO_stdin_used+11) and $0xa73,eax

Nu staat klaasje op het adress van 0x8048454 want bij x/s geeft die

0x8048454 (_IO_stdin_used+4) "klaasje"

Bij disas 0x804845b staat achter (_IO_stdin_used+4) push $0x6f6c6c65
betekend dat $0x6f6c6c65 de pointer is ?

char name[] Heb ik trouwens nog steeds niet terug kunnen vinden.