Re: [libposix-development] Some restructuring, preliminary (non-functional) x86-64 port

[Henrique A. <hd...@gm...>]

2009/6/3 Andreas Krennmair <akr...@go...>:
>
> As far as I understand, the whole vsyscall thing isn't universally
> applicable, and shouldn't be, either. Also, IIRC, vsyscalls don't play
> together too well with strace.
>
> Also:
> $ ldd /bin/ls
>         librt.so.1 => /lib/librt.so.1 (0x00002b0a91436000)
>         libselinux.so.1 => /lib/libselinux.so.1 (0x00002b0a9163e000)
>         libacl.so.1 => /lib/libacl.so.1 (0x00002b0a9185a000)
>         libc.so.6 => /lib/libc.so.6 (0x00002b0a91a61000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x00002b0a91db5000)
>         /lib64/ld-linux-x86-64.so.2 (0x00002b0a91218000)
>         libdl.so.2 => /lib/libdl.so.2 (0x00002b0a91fd0000)
>         libattr.so.1 => /lib/libattr.so.1 (0x00002b0a921d4000)
> $
> No linux-vdso.so.1 here whatsoever.

 Sounds good to me. I just needed the citation. It's available in the
amd64 ABI, in the pages you've cited (obviously, we have to trust that
the ABI will be followed, but the standanrdard is a great
authoritative reference ;-)). So we can throw vsyscall away.

>
>>
>> - _start.S: is the third parameter (envp) correct ? It needs to point
>> to the first environment variable. Isn't the correct address
>> rsi+8*rdi+16 ?
>
> When stepping through the code using gdb, envp seemed to be fine. Also,
> rsi+8*rdi computes the position of the last element in argv (which is NULL),
> and so +8 points to the element next to it, which should be envp.

 Ok, the missing +8 was hidden in the first popq instruction.

>
>
> It's from the Linux kernel's arch/x86/include/asm/unistd_64.h, with some vim
> magic applied. If this is unacceptable, then, well, we have a problem, as
> this is more or less the official reference. And even though FreeBSD has a
> Linux emulation, it doesn't seem to have support for Linux x86_64 syscalls,
> at least I couldn't find anything.

 Ok, we'll need to read the linux source sometimes, because there are
things that are only documented in the source. We can only hope that
building a linux library is not considered a derivative work.

>
>
> Why would I need to save registers for the caller? I don't know which
> registers are used by the caller, so I don't know which to save.
>
> Regarding calling conventions: http://www.x86-64.org/documentation/abi.pdf
> pp. 123-124

 That's it, I just needed the reference. ;-) Elaborating: the caller
and callee must agree on who saves which registers. This is part of
the ABI. The calling conventions is further described in 3.2.3
Parameter Passing. Figure 3.4 shows that registers rax, rcx, rdx, rsi,
rdi, r8-r11 are not preserved across calls, so they can be safely
overwritten.

 Conclusion, the code is conformant. I'll add the references to the
ABI as a remark to the sources. I've installed a x86_64 linux and
hello is working flawlessly. :-)

>
> As I don't have any *BSD installations and only a Mac with an obsolete
> version of OSX that wouldn't be of much help, in the meantime I would prefer
> to work on getting the most essential system calls and some surrounding
> library infrastructure (e.g. malloc(3)) up and running, if that's ok.

 No problem. Post the functions you're working on the list, so that
people can start writing unit tests for them.

>
> I'd prefer sticking to GNU make and Makefiles, as it's powerful enough to
> solve most problems, even multi-platform support. "if it ain't broken, don't
> fix it."
> If you tell me what you want to achieve, I will adapt the Makefile for you.

 That power is exactly what I don't want in our build system. It's a
goal of this project to keep the code easy to study and easy to
mantain, and we all know how large makefiles look like. Consider that
ideally, we'd create a simple source list and the build system would
handle everything. Don't worry, we'll switch to some simpler build
system and if we find out that it's worse or it's too weak, we can
always go back.

>
> Regards,
> Andreas
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> Libposix-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libposix-development
>
>



-- 
 Henrique Dante de Almeida
 hd...@gm...