[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pcc-list
Subject:    Re: [pcc] amd64 thoughts
From:       Anders Magnusson <ragge () ludd ! ltu ! se>
Date:       2009-05-31 10:01:39
Message-ID: 4A225583.3000301 () ludd ! ltu ! se
[Download RAW message or body]

Joshua Keyes wrote:
>> Which linux dialect are you using?  I just tried on CentOS 5.3, and after adding amd64
>> to autoconf the resulting code worked:
>>> echo 'main(){ return 42; }' | ./ccom | as -o x.o ; gcc x.o ; ./a.out; echo $status
>> 42
>>> uname -m -o
>> x86_64 GNU/Linux
>>
>> I would suspect it has something to do with the dynamic linker, have you tried a static binary?
>>
> 
> I use Gentoo 2008 amd64. I also use the 'pcc' binary which is installed during the
> 'make install', from a custom built ebuild that downloads directly from the CVS repository. 
> The example I used is not statically built. I also believe it is a dynamic linker issue but one 
> that seems trivial to fix. Glibc needs %rbx to be preserved upon return from main() in order 
> to register built-in atexit() functions which are called in the exit() routine. I compiled my 
> example source with 'pcc -g -o test test.c' after installing pcc.
> 
rbx is a callee-saved (permanent) register, and as you can see it is never touched.  And because
it works fine if linked with gcc, it's probably a linker problem (not linking problem).

>> The index value should be four in the above example; you are giving an int and main() returns an int.
>>
> 
> IIRC, values pushed onto the stack were exactly one word size. On x86, the word size is 
> 4 bytes (32 bits) and on AMD64, the word size is 8 bytes (64 bits). Thus, any stack 
> manipulation ala N(%rbp) or N(%rsp), N should be a multiple of the word size 
> respectively.
> 
Nja, not really, that is true only for function arguments.  For variables on the stack it
is the same alignment as the type has that is used (that is, as in structs).


>> And, as you may note, sizeof(long int[3]) is now 24 :-)
>>
>>> 1. http://trac.cross-lfs.org/ticket/123#comment:7
>>> 2. http://www.x86-64.org/documentation/assembly.html
>>> 3. http://marc.info/?l=pcc-list&m=124283477809090
>>>
> 
> By the [1], [2], and [3] notations, I was refering to the links I placed at the bottom of my 
> original mail. 
> [1] is the respective name of the dynamic linker for each architecture under 
> linux. For x86, it is /lib/ld-linux.so.2 but for AMD64, it is /lib/ld-linux-x86-64.so.2. It is also 
> different for powerpc(64), sparc(64), and the others listed.
Correct.  But there are other parameters that also must be configured for linux,
at least when looking at the gcc -v output :-)
Note that the dynamic linker for amd64 is also specified in the ABI documentation.

> [2] is a basic introduction to what has changed from x86 to AMD64, assembly wise. I 
> was specifically noting that AMD64 can represent position independent code with
> %rip-relative addressing, meaning the conventional method of PIC using %ebx is not 
> necessary.
Yes, and that is very convenient.  Almost like vax, where everything can be pc-relative :-)

-- Ragge

> [3] was related to word size, in relation to my explanation of stack manipulation.
> 
> --
> Joshua Keyes
> stable [dot] entropy [at] gmail [dot] com
> 


[prev in list] [next in list] [prev in thread] [next in thread]