Thread: [libposix-development] Some restructuring, preliminary (non-functional) x86-64 port
Status: Pre-Alpha
Brought to you by:
hdante
Menu
▾
▴
libposix-development
|
From: Andreas K. <akr...@go...> - 2009-06-02 14:08:26
|
Hello everyone, I restructured the directory structure a bit, and added a preliminary x86-64 port which doesn't work yet, though, as calls to syscall3() somehow jump to the wrong address... Anyway, here's the patch: http://synflood.at/tmp/libposix/x86_64.mbox I'll continue investigating what's going on here. Regards, Andreas |
|
From: Andreas K. <akr...@go...> - 2009-06-02 21:11:18
|
On Tue, Jun 2, 2009 at 3:55 PM, Andreas Krennmair <akr...@go... > wrote: > Hello everyone, > > I restructured the directory structure a bit, and added a preliminary > x86-64 port which doesn't work yet, though, as calls to syscall3() somehow > jump to the wrong address... > Anyway, here's the patch: http://synflood.at/tmp/libposix/x86_64.mbox > I'll continue investigating what's going on here. This patch is obsolete, here's the new patch set containing both the old patch and some amendments to it that make it work on x86_64: http://synflood.at/tmp/libposix/x86_64-working.mbox Please note that this not only switches from nasm to GNU as but also breaks current x86 support as I don't have a proper development machine to test any changes to x86. But changes to get x86 running again should be trivial. So, in short: libposix has gone multiplatform! Regards, Andreas |
|
From: Tordek <ke...@gm...> - 2009-06-02 22:41:04
Attachments:
smime.p7s
|
Andreas Krennmair wrote: > So, in short: libposix has gone multiplatform! > Hate to be the bearer of bad news, but not quite: :~/src/C/libposix$ LD_LIBRARY_PATH=output-x86_64 output-x86_64/hello <Nothing until I press Enter.> Segmentation fault > Regards, > Andreas -- Guillermo O. «Tordek» Freschi. Programador, Escritor, Genio Maligno. http://tordek.com.ar :: http://twitter.com/tordek http://www.arcanopedia.com.ar - Juegos de Rol en Argentina |
|
From: Tordek <ke...@gm...> - 2009-06-02 22:52:01
Attachments:
smime.p7s
|
Disregard that last message, I applied the old patch by mistake. Andreas, you, officially, rock. -- Guillermo O. «Tordek» Freschi. Programador, Escritor, Genio Maligno. http://tordek.com.ar :: http://twitter.com/tordek http://www.arcanopedia.com.ar - Juegos de Rol en Argentina |
|
From: Henrique A. <hd...@gm...> - 2009-06-03 02:26:44
|
2009/6/2 Andreas Krennmair <akr...@go...>: > On Tue, Jun 2, 2009 at 3:55 PM, Andreas Krennmair > > This patch is obsolete, here's the new patch set containing both the old > patch and some amendments to it that make it work on x86_64: > http://synflood.at/tmp/libposix/x86_64-working.mbox Nice. Many comments, though: - x86_64 also seems to use vsyscall, as shown by the virtual library "vdso" shown by Tordek output (ldd /bin/ls) on the other post. Is it safe to use "syscall" directly ? I need a valid reference for the system call specification on x86_64. - _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 ? - syscall_nums.h: It seems that you've copied and pasted those. That can't be done. The original license and author must be present in the source. Also, that license needs to be BSD (the project will have a single license, I'll talk about this). Also, is this from a GPL libc ? We can't refer to GPL competitors, else our library will become a "derivative work" and we'll need to relicense it as GPL. - syscalls.S: are you sure you don't need to save the register values for the caller ? Would the code compiled, say, as -O3 (with the compiler inlining functions and aggressively using registers) always work ? Again, I need a valid reference for the calling conventions specification on x86_64 I have setup a branch for your patches in my local repository, so you can have some time to answer the questions. > > Please note that this not only switches from nasm to GNU as but also breaks > current x86 support as I don't have a proper development machine to test any > changes to x86. But changes to get x86 running again should be trivial. Yes, x86 compilation is broken. :-/ > > So, in short: libposix has gone multiplatform! Cool ! :-D The next step is port to a non linux platform. David said he had easy access to NetBSD and Mac OS X. David, do you think you can help with the port for those ? Anyway, before we continue with the ports, it's a good idea to switch to a "next generation" build system and define how "platform set" configuration files will behave. > > 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... |
|
From: Henrique A. <hd...@gm...> - 2009-06-03 03:03:59
|
BTW, I hope to install Ubuntu amd64 here this week, so I'll be able to help with the port. 2009/6/2 Henrique Almeida <hd...@gm...>: > 2009/6/2 Andreas Krennmair <akr...@go...>: >> On Tue, Jun 2, 2009 at 3:55 PM, Andreas Krennmair >> >> This patch is obsolete, here's the new patch set containing both the old >> patch and some amendments to it that make it work on x86_64: >> http://synflood.at/tmp/libposix/x86_64-working.mbox > > Nice. Many comments, though: > > - x86_64 also seems to use vsyscall, as shown by the virtual library > "vdso" shown by Tordek output (ldd /bin/ls) on the other post. Is it > safe to use "syscall" directly ? I need a valid reference for the > system call specification on x86_64. > - _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 ? > - syscall_nums.h: It seems that you've copied and pasted those. That > can't be done. The original license and author must be present in the > source. Also, that license needs to be BSD (the project will have a > single license, I'll talk about this). Also, is this from a GPL libc ? > We can't refer to GPL competitors, else our library will become a > "derivative work" and we'll need to relicense it as GPL. > - syscalls.S: are you sure you don't need to save the register values > for the caller ? Would the code compiled, say, as -O3 (with the > compiler inlining functions and aggressively using registers) always > work ? Again, I need a valid reference for the calling conventions > specification on x86_64 > > I have setup a branch for your patches in my local repository, so you > can have some time to answer the questions. > >> >> Please note that this not only switches from nasm to GNU as but also breaks >> current x86 support as I don't have a proper development machine to test any >> changes to x86. But changes to get x86 running again should be trivial. > > Yes, x86 compilation is broken. :-/ > >> >> So, in short: libposix has gone multiplatform! > > Cool ! :-D The next step is port to a non linux platform. David said > he had easy access to NetBSD and Mac OS X. David, do you think you can > help with the port for those ? > > Anyway, before we continue with the ports, it's a good idea to switch > to a "next generation" build system and define how "platform set" > configuration files will behave. > >> >> 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... > -- Henrique Dante de Almeida hd...@gm... |
|
From: Andreas K. <akr...@go...> - 2009-06-03 08:28:00
|
On Wed, Jun 3, 2009 at 4:26 AM, Henrique Almeida <hd...@gm...> wrote: > 2009/6/2 Andreas Krennmair <akr...@go...>: > > On Tue, Jun 2, 2009 at 3:55 PM, Andreas Krennmair > > > > This patch is obsolete, here's the new patch set containing both the old > > patch and some amendments to it that make it work on x86_64: > > http://synflood.at/tmp/libposix/x86_64-working.mbox > > Nice. Many comments, though: > > - x86_64 also seems to use vsyscall, as shown by the virtual library > "vdso" shown by Tordek output (ldd /bin/ls) on the other post. Is it > safe to use "syscall" directly ? I need a valid reference for the > system call specification on x86_64. 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. > > - _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. > > - syscall_nums.h: It seems that you've copied and pasted those. That > can't be done. The original license and author must be present in the > source. Also, that license needs to be BSD (the project will have a > single license, I'll talk about this). Also, is this from a GPL libc ? > We can't refer to GPL competitors, else our library will become a > "derivative work" and we'll need to relicense it as GPL. 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. > - syscalls.S: are you sure you don't need to save the register values > for the caller ? Would the code compiled, say, as -O3 (with the > compiler inlining functions and aggressively using registers) always > work ? Again, I need a valid reference for the calling conventions > specification on x86_64 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.pdfpp. 123-124 > Cool ! :-D The next step is port to a non linux platform. David said > he had easy access to NetBSD and Mac OS X. David, do you think you can > help with the port for those ? 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. > Anyway, before we continue with the ports, it's a good idea to switch > to a "next generation" build system and define how "platform set" > configuration files will behave. 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. Regards, Andreas |
|
From: Henrique A. <hd...@gm...> - 2009-06-03 22:04:01
|
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... |
|
From: Andreas K. <akr...@go...> - 2009-06-03 18:36:03
|
Hi, - syscall_nums.h: It seems that you've copied and pasted those. That >> can't be done. The original license and author must be present in the >> source. Also, that license needs to be BSD (the project will have a >> single license, I'll talk about this). Also, is this from a GPL libc ? >> We can't refer to GPL competitors, else our library will become a >> "derivative work" and we'll need to relicense it as GPL. > > > 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, I did find something usable now: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/compat/linux/arch/amd64/linux_syscall.h?rev=1.32&content-type=text/x-cvsweb-markup I'll correct this in my source and release a new patch. Regards, Andreas |
|
From: Andreas K. <akr...@go...> - 2009-06-03 18:48:02
|
On Wed, Jun 3, 2009 at 8:35 PM, Andreas Krennmair <akr...@go... > wrote: > Hi, > > - syscall_nums.h: It seems that you've copied and pasted those. That >>> can't be done. The original license and author must be present in the >>> source. Also, that license needs to be BSD (the project will have a >>> single license, I'll talk about this). Also, is this from a GPL libc ? >>> We can't refer to GPL competitors, else our library will become a >>> "derivative work" and we'll need to relicense it as GPL. >> >> >> 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, I did find something usable now: > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/compat/linux/arch/amd64/linux_syscall.h?rev=1.32&content-type=text/x-cvsweb-markup > I'll correct this in my source and release a new patch. > Here we go: http://synflood.at/tmp/libposix/x86_64-working-updated.mbox It's nothing but a verbatim copy of said file, which is a bit rough, but it's a start to keep the x86_64 port unencumbered. Regards, Andreas |
|
From: Henrique A. <hd...@gm...> - 2009-06-03 22:38:17
|
Applied. Do you know if we can add the third clause to the NetBSD license ? 2009/6/3 Andreas Krennmair <akr...@go...>: > On Wed, Jun 3, 2009 at 8:35 PM, Andreas Krennmair > <akr...@go...> wrote: >> >> Hi, >> >>>> - syscall_nums.h: It seems that you've copied and pasted those. That >>>> can't be done. The original license and author must be present in the >>>> source. Also, that license needs to be BSD (the project will have a >>>> single license, I'll talk about this). Also, is this from a GPL libc ? >>>> We can't refer to GPL competitors, else our library will become a >>>> "derivative work" and we'll need to relicense it as GPL. >>> >>> 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, I did find something usable now: >> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/compat/linux/arch/amd64/linux_syscall.h?rev=1.32&content-type=text/x-cvsweb-markup >> I'll correct this in my source and release a new patch. > > Here we go: http://synflood.at/tmp/libposix/x86_64-working-updated.mbox > > It's nothing but a verbatim copy of said file, which is a bit rough, but > it's a start to keep the x86_64 port unencumbered. > > 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... |
|
From: Andreas K. <akr...@go...> - 2009-06-04 00:01:45
|
On Thu, Jun 4, 2009 at 12:38 AM, Henrique Almeida <hd...@gm...> wrote: > Applied. Did you do git push? Because I don't see it. Regards, Andreas |
|
From: Henrique A. <hd...@gm...> - 2009-06-04 00:11:18
|
I can't, x86 build is broken. 2009/6/3 Andreas Krennmair <akr...@go...>: > On Thu, Jun 4, 2009 at 12:38 AM, Henrique Almeida <hd...@gm...> wrote: >> >> Applied. > > Did you do git push? Because I don't see it. > > 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... |
|
From: Andreas K. <akr...@go...> - 2009-06-04 08:51:34
|
Why not, if I may ask? It's not like a broken build suddenly stops git push from working. Or do you always want to have a functioning build in git master? On Thu, Jun 4, 2009 at 2:11 AM, Henrique Almeida <hd...@gm...> wrote: > I can't, x86 build is broken. > > 2009/6/3 Andreas Krennmair <akr...@go...>: > > On Thu, Jun 4, 2009 at 12:38 AM, Henrique Almeida <hd...@gm...> > wrote: > >> > >> Applied. > > > > Did you do git push? Because I don't see it. > > > > 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... > > > ------------------------------------------------------------------------------ > 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 > |
|
From: Tordek <ke...@gm...> - 2009-06-04 10:53:16
|
> Or do you always want to have a functioning build in git > master? Seems like the right thing to do. Perhaps we can push an "unstable" branch alongside master? |
|
From: Andreas K. <akr...@go...> - 2009-06-04 10:57:09
|
On Thu, Jun 4, 2009 at 12:53 PM, Tordek <ke...@gm...> wrote: > > Or do you always want to have a functioning build in git > > master? > > Seems like the right thing to do. Perhaps we can push an "unstable" > branch alongside master? Only at a certain maturity level, IMHO. Currently I feel it's slowing down development, especially since Henrique and I seem to be in completely different timezones. Regards, Andreas |
|
From: Henrique A. <hd...@gm...> - 2009-06-04 12:53:33
|
2009/6/4 Andreas Krennmair <akr...@go...>: > > > On Thu, Jun 4, 2009 at 12:53 PM, Tordek <ke...@gm...> wrote: >> >> > Or do you always want to have a functioning build in git >> > master? >> >> Seems like the right thing to do. Perhaps we can push an "unstable" >> branch alongside master? > > Only at a certain maturity level, IMHO. Currently I feel it's slowing down > development, especially since Henrique and I seem to be in completely > different timezones. We can have a "broken" branch. I'll add that later. My "official" work hour for libposix is around 0h UTC. I read e-mails frequently, though. > > 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... |
|
From: Henrique A. <hd...@gm...> - 2009-06-04 12:52:47
|
2009/6/4 Andreas Krennmair <akr...@go...>: > Why not, if I may ask? It's not like a broken build suddenly stops git push > from working. Or do you always want to have a functioning build in git > master? The current message is: gcc -std=c99 -Iinclude -Icompiler/gcc -Iruntime -Wall -Wextra -g -nostdlib -fPIC -Isystem/linux -Isystem/linux/i386 -c system/linux/syscalls.c -o output-i386/syscalls.o system/linux/syscalls.c:30:26: error: syscall_nums.h: Arquivo ou diretório inexistente system/linux/syscalls.c: In function ‘write’: system/linux/syscalls.c:34: error: ‘LINUX_SYS_write’ undeclared (first use in this function) system/linux/syscalls.c:34: error: (Each undeclared identifier is reported only once system/linux/syscalls.c:34: error: for each function it appears in.) system/linux/syscalls.c: In function ‘_Exit’: system/linux/syscalls.c:39: error: ‘LINUX_SYS_exit’ undeclared (first use in this function) system/linux/syscalls.c:40: warning: ‘noreturn’ function does return make: ** [output-i386/syscalls.o] Erro 1 SF repository is for code that always work. Broken commits must stay in local repositories. > > On Thu, Jun 4, 2009 at 2:11 AM, Henrique Almeida <hd...@gm...> wrote: >> >> I can't, x86 build is broken. >> >> 2009/6/3 Andreas Krennmair <akr...@go...>: >> > On Thu, Jun 4, 2009 at 12:38 AM, Henrique Almeida <hd...@gm...> >> > wrote: >> >> >> >> Applied. >> > >> > Did you do git push? Because I don't see it. >> > >> > 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... >> >> >> ------------------------------------------------------------------------------ >> 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 > > > ------------------------------------------------------------------------------ > 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... |
|
From: Andreas K. <akr...@go...> - 2009-06-04 13:14:47
|
On Thu, Jun 4, 2009 at 2:46 PM, Henrique Almeida <hd...@gm...> wrote: > 2009/6/4 Andreas Krennmair <akr...@go...>: > > Why not, if I may ask? It's not like a broken build suddenly stops git > push > > from working. Or do you always want to have a functioning build in git > > master? > > The current message is: > > gcc -std=c99 -Iinclude -Icompiler/gcc -Iruntime -Wall -Wextra -g > -nostdlib -fPIC -Isystem/linux -Isystem/linux/i386 -c > system/linux/syscalls.c -o output-i386/syscalls.o > system/linux/syscalls.c:30:26: error: syscall_nums.h: Arquivo ou > diretório inexistente > system/linux/syscalls.c: In function ‘write’: > system/linux/syscalls.c:34: error: ‘LINUX_SYS_write’ undeclared (first > use in this function) > system/linux/syscalls.c:34: error: (Each undeclared identifier is > reported only once > system/linux/syscalls.c:34: error: for each function it appears in.) > system/linux/syscalls.c: In function ‘_Exit’: > system/linux/syscalls.c:39: error: ‘LINUX_SYS_exit’ undeclared (first > use in this function) > system/linux/syscalls.c:40: warning: ‘noreturn’ function does return > make: ** [output-i386/syscalls.o] Erro 1 Please the contents of http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/compat/linux/arch/i386/linux_syscall.h?rev=1.83&content-type=text/x-cvsweb-markupinto system/linux/i386/syscall_nums.h, then that should work. > SF repository is for code that always work. Broken commits must stay > in local repositories. ... which depends on the definition of "working" and "broken". Anyway, good luck with that, not every developer will have all supported operating systems on all supported architectures available to check for breakages prior to a commit. Heck, I don't even have an x86 machine available. Regards, Andreas |
|
From: Henrique A. <hd...@gm...> - 2009-06-04 17:22:31
|
2009/6/4 Andreas Krennmair <akr...@go...>: > > > > Please the contents of > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/compat/linux/arch/i386/linux_syscall.h?rev=1.83&content-type=text/x-cvsweb-markup > into system/linux/i386/syscall_nums.h, then that should work. > > > ... which depends on the definition of "working" and "broken". Anyway, good > luck with that, not every developer will have all supported operating > systems on all supported architectures available to check for breakages > prior to a commit. Heck, I don't even have an x86 machine available. I'll backport the changes to x86 today. If there's something blocking your work, you can warn me and I'll prioritize the solution. The "broken" branch is up. > > 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... |
|
From: Henrique A. <hd...@gm...> - 2009-06-05 02:15:31
|
2009/6/4 Henrique Almeida <hd...@gm...>: > > I'll backport the changes to x86 today. If there's something blocking > your work, you can warn me and I'll prioritize the solution. Done. > > The "broken" branch is up. > > > > > -- > Henrique Dante de Almeida > hd...@gm... > -- Henrique Dante de Almeida hd...@gm... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X