similar to: [PATCH] stubdom: prevent newlib from emiting cli/sti in longjmp

stubdom: fix build dependency newlib now depends on mini-os header links diff -r 4c2d9a4d11f2 stubdom/Makefile --- a/stubdom/Makefile Fri Jul 18 13:58:29 2008 +0100 +++ b/stubdom/Makefile Fri Jul 18 14:19:52 2008 +0100 @@ -86,7 +86,7 @@ NEWLIB_STAMPFILE=$(CROSS_ROOT)/$(GNU_TARGET_ARCH)-xen-elf/lib/libc.a .PHONY: cross-newlib cross-newlib: $(NEWLIB_STAMPFILE) -$(NEWLIB_STAMPFILE):

I am updating this patch to use the tools/ioemu-dir symlink as qemu source directory in case CONFIG_QEMU != ioemu. Before we were trying to figure out where is the actual qemu source dir again. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- diff -r f5e72cbfbb17 stubdom/Makefile --- a/stubdom/Makefile Wed Sep 10 11:26:16 2008 +0100 +++ b/stubdom/Makefile Thu Sep

stubdom: do not build tapdisk as it it not supposed to build and we don''t need it Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com> diff -r 4024164e7572 stubdom/Makefile --- a/stubdom/Makefile Tue Jul 08 16:11:49 2008 +0100 +++ b/stubdom/Makefile Tue Jul 08 17:12:38 2008 +0100 @@ -190,7 +190,7 @@ [ -f ioemu/config-host.mak ] || \ ( cd ioemu ; \

Just for the archive or in case of anybody is interested in: The problem is the missing stddef.h which resides more than one time on the OS. I mistakenly thought, that there is an typo in the code, because one of this files is in /us/include/linux so I changed #include <stddef.h> to #include <linux/stddef.h> But this was wrong and it is the wrong file too. The right file to

I am trying to build xen-3.3.0 and I keep running into this error. I have checked and everything is there and installed and the PATH is correct. I found someone on the 15th who also had the same problem but never got a reply back so I am asking again. Here is the error: make[2]: Entering directory `/usr/src/xen-3.3.0/extras/mini-os'' [ -e include/xen ] || ln -sf

A few things - 1. I think that run-time processor detection should not be included in Speex. 2. There a few ways of doing per-file compiling flags. a. Make a new static library that is just the files that have the SSE / Altivec code in them. You can then use target_CFLAGS in the Makefile.am script to set what you need b. Do tricks with file extensions. CFLAGS applies to

Changes from v3: - mini-os configuration files moved into stubdom/ - mini-os extra console support now a config option - Fewer #ifdefs - grant table setup uses hypercall bounce - Xenstore stub domain syslog support re-enabled Changes from v2: - configuration support added to mini-os build system - add mini-os support for conditionally compiling frontends, xenbus -

Does anyone on this list have experience with newlib? I'm thinking of porting newlib to the COM32 environment, rather than trying to hack my own mini-libc. I just wondered if anyone had any idea of how well that would be likely to work, and/or how well newlib works from a code size standpoint... -hpa

I'd be happy to transfer my code and a brain dump on where I was intended to go with it to anyone who'd be willing to take over the effort. The bottom line is that I just don't have time, nor do I expect to have any time during this year. -hpa

Hi Reid, I'll write a separate post about the intrinsics, but just a quick note about the CFLAGS issue. Reid Spencer kirjoitti: > On Thu, 2006-11-09 at 15:29 +0200, Pertti Kellomäki wrote: >> Another related thing is that even when I defined -emit-llvm in >> what I thought would be a global CFLAGS for all of newlib, it did >> not get propagated to all subdirectories.

Hi Pertti, On Thu, 2006-11-09 at 18:41 +0200, Pertti Kellomäki wrote: > Hi Reid, > > I'll write a separate post about the intrinsics, but just > a quick note about the CFLAGS issue. Okay. > > Reid Spencer kirjoitti: > > On Thu, 2006-11-09 at 15:29 +0200, Pertti Kellomäki wrote: > >> Another related thing is that even when I defined -emit-llvm in >

Reid Spencer kirjoitti: > So, now I'm not sure what you're talking about. Is > libgloss part of newlib? If so, please note that it is not llvm-gcc's > job to pass CFLAGS down. That would be a bug in the newlib makefiles. :) Sorry for being obtuse. Yes, if there indeed is a bug, it is in the newlib build system. I was trying to compile newlib with llvm-gcc. The need for

On Thu, 9 Nov 2006, [ISO-8859-1] Pertti Kellom�ki wrote: > to identify that we are compiling to LLVM byte code. If there is > one, I'd be happy to hear it, but if not, then it might be a good > idea to define __LLVM__ or something like that in (by) llvm-gcc. llvm-gcc defines __llvm__. -Chris -- http://nondot.org/sabre/ http://llvm.org/

On Thu, 9 Nov 2006, Reid Spencer wrote: >> Currently there are a few intrinsics that have >> to do with libc, like llvm.memcpy and llvm.memmove. However, I >> would personally prefer less pollution in the intrinsic name space, >> so I would propose naming the intrinsics with a llvm.libc prefix, >> e.g. llvm.libc.open and so forth. Any strong opinions on this? >

Chris Lattner kirjoitti: > There isn't any really good reason to have an llvm intrinsic for write, > just leave 'write' as an external function. So is the opportunity for inlining the only reason for e.g. the llvm.memcpy intrinsic? -- Pertti

On Thu, 9 Nov 2006, Markus F.X.J. Oberhumer wrote: > > llvm-gcc defines __llvm__. > Could we add some more detailed version information to the frontend, > e.g. such as a predefined -D__llvm_bytecode_version__=6 ? Why do you need this? -Chris -- http://nondot.org/sabre/ http://llvm.org/

Chris Lattner kirjoitti: > llvm-gcc defines __llvm__. Thanks. I thought I tried it, but apparently not. -- Pertti

Pertti Kellomäki wrote: > Chris Lattner kirjoitti: > >>llvm-gcc defines __llvm__. > > > Thanks. I thought I tried it, but apparently not. Try: <path-to-llvm-gcc-install>/llvm-cpp -dM /dev/null | grep -y llvm llvm-cpp should be installed if you built the gcc frontend. Mine reports __llvm__. BTW: Would be nice if the frontend defined a manifest constant if it is

On Thu, 9 Nov 2006, Scott Michel wrote: > BTW: Would be nice if the frontend defined a manifest constant if it is > generating byte code vice generating native. But that's a refinement for > another day... Why? As an end user, I'd be very unhappy if I got different code from -emit-llvm + llc then from normal llvm-gcc. -Chris -- http://nondot.org/sabre/ http://llvm.org/

Chris Lattner wrote: > On Thu, 9 Nov 2006, Scott Michel wrote: > >> BTW: Would be nice if the frontend defined a manifest constant if it is >> generating byte code vice generating native. But that's a refinement for >> another day... > > > Why? As an end user, I'd be very unhappy if I got different code from > -emit-llvm + llc then from normal