Is anyone interested in starting a thread on x86-64 assembly language?

As a starting point, there is (for Linux, and maybe the BSDs too):
http://www.x86-64.org/documentation/abi.pdf. This is the System V ABI
Draft 0.97.

For Windows x86-64, a Google search reveals some resources for x64
assembly language programmers, but the best resource is of course from
MS themselves, which is in the Win2k3 SP1 SDK.

If anyone knows, are there any problems with this code?  (Using YASM). 
It runs fine when linking through GCC, but not when I use as and then
ld (seg fault on return from main).  The command lines:

Causes segfault after ret from main:
$ yasm -f elf -m amd64 -g stabs -o cpuid.obj cpuid.asm
$ ld -dynamic-linker /lib64/ld-linux-x86-64.so.2 -lc \
-e main -o cpuid cpuid.obj

OK:
$ yasm -f elf -m amd64 -g stabs -o cpuid.obj cpuid.asm
$ gcc -o cpuid cpuid.obj

[BITS 64]

[SECTION .data]
align 8
vendor: db "The Processor Vendor ID is '%s'",10,0

[SECTION .bss]
align 8
buffer: resb 13

[SECTION .text]
align 8

[GLOBAL main]
[EXTERN printf]

main:
        push rbp
        mov rbp, rsp
        
        ; ABI says to save if using rbx or r12 - r15
        push rbx

        xor rax, rax
        cpuid

        mov [buffer], dword ebx
        mov [buffer+4], dword edx
        mov [buffer+8], dword ecx

        ; cpuid clobbers rax
        ; al is hidden argument to save SSE registers
        xor rax, rax
        mov rdi, vendor
        mov rsi, buffer
        call printf

        pop rbx

        xor rax, rax
        leave
        ret


Cheers,
James

James Buchanan wrote:
> Is anyone interested in starting a thread on x86-64 assembly language?

You just did! :)

> As a starting point, there is (for Linux, and maybe the BSDs too):
> http://www.x86-64.org/documentation/abi.pdf. This is the System V ABI
> Draft 0.97.
> 
> For Windows x86-64, a Google search reveals some resources for x64
> assembly language programmers, but the best resource is of course from
> MS themselves, which is in the Win2k3 SP1 SDK.
> 
> If anyone knows, are there any problems with this code?  (Using YASM). 
> It runs fine when linking through GCC, but not when I use as and then
> ld (seg fault on return from main).  The command lines:
> 
> Causes segfault after ret from main:
> $ yasm -f elf -m amd64 -g stabs -o cpuid.obj cpuid.asm
> $ ld -dynamic-linker /lib64/ld-linux-x86-64.so.2 -lc \
> -e main -o cpuid cpuid.obj
> 
> OK:
> $ yasm -f elf -m amd64 -g stabs -o cpuid.obj cpuid.asm
> $ gcc -o cpuid cpuid.obj

[snip]
.....
>         ret

I don't know squat about 64-bit, but in 32-bit (and I suspect it's the 
problem here), you can end with a "ret" if your entrypoint is "call"ed - 
by the C startup code, e.g. If the entrypoint, is given to "ld" 
("_start" is the default entry symbol, but we've changed it to "main" 
with the "-e" switch), that entrypoint is *not* called, but "jmp"ed to. 
There's no return address on the stack (starts right out with "argc", in 
32-bit). So we need to end with "sys_exit", or probably calling the C 
"exit()" would work(?). According to some posts to this NG back in 
mid-August (from "bwaichu"), the 64-bit sys_exit (this is for BSD, not 
Linux!) would look like:

xor rdi, rdi
mov eax, 1
syscall

The C exit would probably be:

push 0
call exit

..... maybe "_exit"?... declare it as "extern", of course.

Also, you're not cleaning up the stack after the "printf" call. As a 
wild guess:

add rsp, 20

The fact that your code works if linked with C startup code suggests 
that this may not be neccessary(???).

Despite the fact that I'm not doing 64-bit (still running a K2-300!), 
I'm interested in reading about it, so "carry on". Please.

Best,
Frank

Frank Kotler wrote:
>> Is anyone interested in starting a thread on x86-64 assembly language?
>
> You just did! :)

So I did... ;-)

> I don't know squat about 64-bit, but in 32-bit (and I suspect it's the 
> problem here), you can end with a "ret" if your entrypoint is "call"ed - 
> by the C startup code, e.g. If the entrypoint, is given to "ld" 
> ("_start" is the default entry symbol, but we've changed it to "main" 
> with the "-e" switch), that entrypoint is *not* called, but "jmp"ed to.
> There's no return address on the stack (starts right out with "argc", in 
> 32-bit). So we need to end with "sys_exit", or probably calling the C 
> "exit()" would work(?). According to some posts to this NG back in 
> mid-August (from "bwaichu"), the 64-bit sys_exit (this is for BSD, not 
> Linux!) would look like:
> 
> xor rdi, rdi
> mov eax, 1
> syscall

Ah, of course.  I'm looking through the glibc source code at the moment 
trying to find out exactly what's going on.  It appears that the ld 
authors are using the Intel386/SysV 4 ABI, not the System V ELF-64 ABI, 
or so the comments say, unless they are substantially similar and 
Intel386/SysV 64-bit supplement to the ABI was used before the most 
recent drafts were out of the ELF-64 ABI written by SuSE and Code 
Sourcery people...

It looks as if the arguments are passed on the stack and in registers, 
too (sysdeps/x86-64/start.S or __startup.S or something like that).  I 
haven't figured out much more than that yet!

> The C exit would probably be:
> 
> push 0
> call exit
> 
> .... maybe "_exit"?... declare it as "extern", of course.

Probably just exit, for ELF.

> Also, you're not cleaning up the stack after the "printf" call. As a 
> wild guess:
> 
> add rsp, 20

I am passing arguments in registers and not on the stack, so it's not 
necessary, unless I am misunderstanding something...

> The fact that your code works if linked with C startup code suggests 
> that this may not be neccessary(???).
> 
> Despite the fact that I'm not doing 64-bit (still running a K2-300!), 
> I'm interested in reading about it, so "carry on". Please.

Thanks very much for your post!  It made me think about whether the ret 
was correct, since main() is just a function like any other, and the ABI 
  (or the one I thought was the correct one to follow) specifies the way 
arguments are passed to functions.  First rdi, then rsi, then rdx and 
rcx, and so on, and if passing in something that's not able to go in 
registers, like the memory class of objects, then on the stack and so on...

I've got a headache already. ;-)

By the way, you can try out a 64-bit Linux in Bochs or on another 
emulator/VM and start hacking some 64-bit assembly.  If Bochs is able to 
run 64-bit systems yet, that is.  VMware probably can, or the latest 5.5 
can IIRC, if you have this software.

Best wishes,
James

James Buchanan wrote:

.....
>> Also, you're not cleaning up the stack after the "printf" call. As a 
>> wild guess:
>>
>> add rsp, 20
> 
> I am passing arguments in registers and not on the stack, so it's not 
> necessary, unless I am misunderstanding something...

Of course! Sorry. I was reading what I "expected" to read, instead of 
what you wrote. This 64-bit stuff is a *completely* different world!

Best,
Frank

James Buchanan wrote:
> Is anyone interested in starting a thread on x86-64 assembly language?
>
> As a starting point, there is (for Linux, and maybe the BSDs too):
> http://www.x86-64.org/documentation/abi.pdf. This is the System V ABI
> Draft 0.97.
>
> For Windows x86-64, a Google search reveals some resources for x64
> assembly language programmers, but the best resource is of course from
> MS themselves, which is in the Win2k3 SP1 SDK.
>
> If anyone knows, are there any problems with this code?  (Using YASM).
> It runs fine when linking through GCC, but not when I use as and then
> ld (seg fault on return from main).  The command lines:
>
> Causes segfault after ret from main:
> $ yasm -f elf -m amd64 -g stabs -o cpuid.obj cpuid.asm
> $ ld -dynamic-linker /lib64/ld-linux-x86-64.so.2 -lc \
> -e main -o cpuid cpuid.obj
>
> OK:
> $ yasm -f elf -m amd64 -g stabs -o cpuid.obj cpuid.asm
> $ gcc -o cpuid cpuid.obj
>
> [BITS 64]
>
> [SECTION .data]
> align 8
> vendor: db "The Processor Vendor ID is '%s'",10,0
>
> [SECTION .bss]
> align 8
> buffer: resb 13
>
> [SECTION .text]
> align 8
>
> [GLOBAL main]
> [EXTERN printf]
>
> main:
>         push rbp
>         mov rbp, rsp
>
>         ; ABI says to save if using rbx or r12 - r15
>         push rbx
>
>         xor rax, rax
>         cpuid
>
>         mov [buffer], dword ebx
>         mov [buffer+4], dword edx
>         mov [buffer+8], dword ecx
>
>         ; cpuid clobbers rax
>         ; al is hidden argument to save SSE registers
>         xor rax, rax
>         mov rdi, vendor
>         mov rsi, buffer
>         call printf
>
>         pop rbx
>
>         xor rax, rax
>         leave
>         ret
>
>
> Cheers,
> James

PLease Start A TUTORIAL in 64-bit Assembly I will be your student.

Why only a thread? Why not a group? Check out the following link

http://groups.google.com/group/x64-Developer-Avenue

I created a new group for x64 assembly developers!

I'm a student working on an assembler for AMD 64 processors as a part
of a larger project and seriously feel that there is almost no or very
little information available on the net for x64 assembly developers.
As a part of my endeavour, I've started the mentioned post and I guess
soon, I'll be starting a website as well, dedicated to x64 assembly and
other topics associated with low leve programming. I intend to develop
a few tools and utilities as well.

Although, I'm not a seasoned assembly programmer, I've been following
these issues for some time and feel that some issues like cross
compilers, porting of operating systems, assembly programming (x64) and
compiler designing are one of the most neglected topics.
I did come across one of your (James'es) post on some other news group
and I've been following your posts since :-)
I think that post was in relation to cross compiling or porting i
guess?

Anyways, I hope to see all x64 developers in my new group soon!!

Please feel free to post messages and check back for links and news!

Thank you!

Sanky wrote:

> Why only a thread? Why not a group? Check out the following link
> 
> http://groups.google.com/group/x64-Developer-Avenue
> 
> I created a new group for x64 assembly developers!

Great stuff. :-)

> I'm a student working on an assembler for AMD 64 processors as a part
> of a larger project and seriously feel that there is almost no or very
> little information available on the net for x64 assembly developers.
> As a part of my endeavour, I've started the mentioned post and I guess
> soon, I'll be starting a website as well, dedicated to x64 assembly
> and other topics associated with low leve programming. I intend to
> develop a few tools and utilities as well.

There is enough out there to get by on, if you're willing to dig it all
up.  For example if you use Windows x64, the MSDN has some info. 
Unfortunately for Linux and BSD users we have nothing much other than a
draft ABI doc and studying the output of "gcc -S program.c" :-(

Also the source code of glibc seems to be referring to the Intel386 ABI
for x86-64!  I thought the ELF SysV ABI was supposed to be the one. 
Unless they are identical, which is unlikely...

> Although, I'm not a seasoned assembly programmer, I've been following
> these issues for some time and feel that some issues like cross
> compilers, porting of operating systems, assembly programming (x64)
> and compiler designing are one of the most neglected topics.

Yes, they are, because they're undocumented/underdocumented black
arts :-)

> I did come across one of your (James'es) post on some other news group
> and I've been following your posts since :-)
> I think that post was in relation to cross compiling or porting i
> guess?

That must have been some Minix stuff I'm doing...

> Anyways, I hope to see all x64 developers in my new group soon!!
> 
> Please feel free to post messages and check back for links and news!

Nice to hear from you.  Take care. :-)

Frank Kotler wrote:
> Of course! Sorry. I was reading what I "expected" to read, instead of
> what you wrote. This 64-bit stuff is a *completely* different world!

It sure is... sometimes arguments go on the stack AND in the
registers... I think that happens for main() when the environment is
being prepared by glibc.  I'll have to chase that up.

>Why only a thread? Why not a group? Check out the following link
>
>http://groups.google.com/group/x64-Developer-Avenue

And how can this one beeing accessed using a newsreader?

Das wrote:
> PLease Start A TUTORIAL in 64-bit Assembly I will be your student.

Sure, when I know enough about it to write a decent tutorial, I'll do
that. :-)