login
Search
[Second try, without clicking "compress" on the file attachment because then sourceforge's spam filter bounces it.] --- > include/asm-generic/tlb.h: In function
Guess most people are not using SMP right now, and that the error disappear= s=20 without that setting - I'm being away for a long while, has SKAS+SMP suppor= t=20 been merged? However, a quick look at my sources tells otherwise, and git-describe says= =20 that's a v2.6.23-rc6-239-gc2f8289 tree. =2D-=20 "Doh!" (cit.), I've made another mistake! Paolo Giarrusso, aka Blaisorblade
It doesn't. It fails with non-SMP as well. Rob, your patch works for me. (Not that the reboot into 2.6.23.1 was problem-free: iproute2-071016 fails to understand the `police' action and also somehow fails to bring up networking well enough for me to locally NFS-mount my home directories, where 070710 had no trouble. More on that soon to the appropriate people as soon as I've diagnosed it...) -
UML still doesn't build on 2.6.23-git16. Gcc threw out many errors, I put them in the web: http://wangcong.org/down/errors.txt My .config is located at: http://wangcong.org/down/uml_config.bak Or I missed something? Regards. -- May the Source Be With You. -
Looks like either you need to run mrproper and try again, or maybe fallout from the x86 merge, with include/asm-um/arch pointing to include/asm-i386 instead of include/asm-x86. Although I though Al had UML building in the presence of the x86 merge. Jeff -- Work email - jdike at linux dot intel dot com -
Hi, Jeff! I have tried `make mrproper' before `make ARCH=um', but it still failed. ;( Regards. -- May the Source Be With You. -
Fallout continues; I've got a preliminary patch for it. Basically, we
need to stop doing -U__i386__ et.al.
diff --git a/arch/um/Makefile-i386 b/arch/um/Makefile-i386
index 0178df3..08433f8 100644
--- a/arch/um/Makefile-i386
+++ b/arch/um/Makefile-i386
@@ -9,6 +9,7 @@ ELF_ARCH := $(SUBARCH)
ELF_FORMAT := elf32-$(SUBARCH)
OBJCOPYFLAGS := -O binary -R .note -R .comment -S
HEADER_ARCH := x86
+CHECKFLAGS += -D__i386__
ifeq ("$(origin SUBARCH)", "command line")
ifneq ("$(shell uname -m | sed -e s/i.86/i386/)", "$(SUBARCH)")
@@ -26,8 +27,6 @@ AFLAGS += -DCONFIG_X86_32
CONFIG_X86_32 := y
export CONFIG_X86_32
-ARCH_KERNEL_DEFINES += -U__$(SUBARCH)__ -U$(SUBARCH)
-
# First of all, tune CFLAGS for the specific CPU. This actually sets cflags-y.
include $(srctree)/arch/i386/Makefile.cpu
diff --git a/arch/um/Makefile-x86_64 b/arch/um/Makefile-x86_64
index fe5316f..8ed362f 100644
--- a/arch/um/Makefile-x86_64
+++ b/arch/um/Makefile-x86_64
@@ -6,12 +6,9 @@ START := 0x60000000
_extra_flags_ = -fno-builtin -m64
-#We #undef __x86_64__ for kernelspace, not for userspace where
-#it's needed for headers to work!
-ARCH_KERNEL_DEFINES = -U__$(SUBARCH)__
KBUILD_CFLAGS += $(_extra_flags_)
-CHECKFLAGS += -m64
+CHECKFLAGS += -m64 -D__x86_64__
KBUILD_AFLAGS += -m64
LDFLAGS += -m elf_x86_64
KBUILD_CPPFLAGS += -m64
diff --git a/arch/um/kernel/sysrq.c b/arch/um/kernel/sysrq.c
index 9326357..96f67d5 100644
--- a/arch/um/kernel/sysrq.c
+++ b/arch/um/kernel/sysrq.c
@@ -8,6 +8,7 @@
#include "linux/module.h"
#include "linux/kallsyms.h"
#include "asm/page.h"
+#include "registers.h"
#include "asm/processor.h"
#include "sysrq.h"
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 0e937f6..20070b7 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -41,7 +41,7 @@
*/
static inline int uncached_access(struct file *file, unsigned long addr)
{
-#if defined(__i386__)
+#if defined(__i386__) && !defined(__arch_um__)
/*
* ...Hi, Al. I applied your patch and recompiled the kernel. But it failed again. ;( Regards. WANG Cong -
Details would be welcome... Notes: SMP on UML is no more; UML_NET_VDE depends on having some userland library installed. Aside of those two it ought to build. Build log on failing build would be nice, along with .config. -
I build UML for non-SMP x86. But I don't know about UML_NET_VDE. ;( Errors threw out by gcc (too many) are put here: http://wangcong.org/down/errors.txt And my .config is located here: http://wangcong.org/down/dot_config (Errors look like same as without your patch.) -- May the Source Be With You. -
It's hard to tell without LOCALE=C, but those are the sorts of results
I'd expect if you had run make {old,menu,x}config without specifying
ARCH=um, so you've configured for one architecture and are now trying
to build another.
Where is the include/asm symlink pointing to in your build tree?
(FWIW I get a coredump if I try to use the skas patch, but with noprocmm
UML in 2.6.23.1 builds and runs perfectly well on x86-32. I haven't
tried 2.6.23, but I see no reason why it should act any differently.)
--
`Some people don't think performance issues are "real bugs", and I think
such people shouldn't be allowed to program.' --- Linus Torvalds
-
$ ls -l include/asm lrwxrwxrwx 1 wangcong wangcong 6 2007-10-22 12:34 include/asm -> asm-um OK. Let me do the following: $ make mrproper ... $ make defconfig ARCH=um ... # # configuration written to .config # $ make ARCH=um (Still tons of errors here...) Am I wrong or I missed something? Regards. -- May the Source Be With You. -
Please try make ARCH=um mrproper this will clean up the additional uml symlinks. Sam -
Hi, Sam, Al and others. I just followed what Sam told me, errors are much fewer this time, but still exist. Error messages are: CC arch/um/kernel/syscall.o CC arch/um/kernel/sysrq.o arch/um/kernel/sysrq.c: In function ‘show_stack’: arch/um/kernel/sysrq.c:63: error: ‘UESP’ undeclared (first use in this function) arch/um/kernel/sysrq.c:63: error: (Each undeclared identifier is reported only once arch/um/kernel/sysrq.c:63: error: for each function it appears in.) make[1]: *** [arch/um/kernel/sysrq.o] Error 1 make: *** [arch/um/kernel] Error 2 Or I missed something again? And I use `make defconfig ARCH=um' to generate .config, my tree is 2.6.23-git16 (Al, is this OK?). Thanks. -- May the Source Be With You. -
that looks like a cut-and-paste error since the file include/asm-um/arch/ptrace-abi.h opens with: =3D=3D=3D=3D=3D #ifndef _ASM_X86_PTRACE_ABI_H #define _ASM_X86_PTRACE_ABI_H #ifdef __i386__ #define EBX 0 #define ECX 1 #define EDX 2 #define ESI 3 #define EDI 4 #define EBP 5 #define EAX 6 #define DS 7 #define ES 8 #define FS 9 #define GS 10 #define ORIG_EAX 11 #define EIP 12 #define CS 13 #define EFL 14 #define UESP 15 =2E.... =3D=3D=3D=3D=3D somehow, that doesn't look right. rday --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Now apply the patch upthread, it should've fixed that one (and yes, you are down to the stuff this patch is supposed to fix - and does so here). -
Yes, this one is fixed. Thanks for your patch. But another one comes out. ;( CC kernel/sched.o kernel/sched.c:3902: error: conflicting types for ‘wait_for_completion_interruptible’ include/linux/completion.h:46: error: previous declaration of ‘wait_for_completion_interruptible’ was here kernel/sched.c:3908: error: conflicting types for ‘wait_for_completion_interruptible’ include/linux/completion.h:46: error: previous declaration of ‘wait_for_completion_interruptible’ was here make[1]: *** [kernel/sched.o] Error 1 make: *** [kernel] Error 2 CC: Ingo Molar <mingo@elte.hu> -- May the Source Be With You. -
Thanks, Ingo! I am using 2.6.23-git16 plus Al's previous patch. After applying your patch, it builds fine. Regards. WANG Cong -
Jeff had posted a fix for that one a while ago: -int __sched wait_for_completion_interruptible(struct completion *x) +int __sched fastcall wait_for_completion_interruptible(struct completion *x) in kernel/sched.c FWIW, I would simply kill the damn fastcall thing - right now the only user is uml/i386; everything else either has it #defined to nothing or (as i386 does) passes -mregparm=3 while having fastcall expand to __attribute__((regparm(3))) - i.e. has all functions fastcall. Do we really need it on uml/i386 enough to keep bothering with that mess? -
we should kill it there too. the only place where we should _please_ keep those annotations are for functions that get called from assembly code. This makes life immensely easier for -pg (CONFIG_FUNCTION_TRACING) kernels. Ingo -
Should we re-add them for the function pointers in asm-x86/paravirt.h?
Andi argued we should remove them since x86 is unconditionally regparm
now anyway - and they're pretty ugly syntactically.
J
-
yes, yes, yes. :-) It was a nightmare to sort it out in -rt (and still is). It's also good documentation - it pinpoints functions that are Sure, it doesnt make things prettier, but i didnt see any particular ugliness. Ingo -
One thought I had is that "fastcall" doesn't really mean the right
thing. The speed or otherwise of the call is a side-effect, but what we
really mean is something like "regparm". Ie, document the actual
calling convention used, rather than an effect of the calling convention.
I guess "fastcall" has enough history now.
J
-
Hm, how can we get gcc to complain about inconsistent use of fastcall?
It doesn't generate any warnings if the function and its pointer are
inconsistent, presumably because everything is regparm(3) anyway...
J
-
yes, attached. Ack?
Ingo
---------------------------->
Subject: [patch] paravirt: mark assembly dependencies as fastcall
From: Ingo Molnar <mingo@elte.hu>
the 'fastcall removal' changes to paravirt.c were over-eager: they
removed fastcall annotations from functions that are (or might be)
implemented in assembly. So if someone changes the compiler model,
such as -pg which disables regparm, the kernel breaks in nasty ways.
so this patch adds back fastcall annotations. This serves as
documentation for assembly calling-convention dependencies as
well.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/i386/kernel/paravirt.c | 6 -
arch/i386/kernel/smp.c | 7 +
include/asm-i386/desc.h | 18 ++--
include/asm-i386/io.h | 2
include/asm-i386/irqflags.h | 12 +-
include/asm-i386/msr.h | 13 +--
include/asm-i386/page.h | 21 ++---
include/asm-i386/paravirt.h | 156 +++++++++++++++++++-------------------
include/asm-i386/pgtable-2level.h | 10 +-
include/asm-i386/pgtable-3level.h | 18 ++--
include/asm-i386/pgtable.h | 2
include/asm-i386/processor.h | 8 -
include/asm-i386/system.h | 22 ++---
include/asm-i386/time.h | 4
include/asm-i386/tlbflush.h | 4
15 files changed, 154 insertions(+), 149 deletions(-)
Index: linux-2.6.23-rt1/arch/i386/kernel/paravirt.c
===================================================================
--- linux-2.6.23-rt1.orig/arch/i386/kernel/paravirt.c 2007-10-11 15:58:08.000000000 -0400
+++ linux-2.6.23-rt1/arch/i386/kernel/paravirt.c 2007-10-11 16:00:03.000000000 -0400
@@ -208,7 +208,7 @@ void init_IRQ(void)
paravirt_ops.init_IRQ();
}
-static void native_flush_tlb(void)
+static fastcall void native_flush_tlb(void)
{
__native_flush_tlb();
}
@@ -217,12 +217,12 @@ static void native_flush_tlb(void)
* Global pages have to be flushed a bit differently. Not a real
* ...It would be probably better to just not disable -mregparms. I don't think the compiler forces this. And e.g. on x86-64 regparms & -pg You should rename it then to "asmcall" or something. -Andi -
if then that should be a separate renaming patch. Ingo -
Well you're asking for the ugly hacks for out of tree code. Any clean ups needed should be your duty (and it's still unclear why exactly regparm should not work with -pg anyways -- before readding ugly stuff perhaps that should be clarified too) -Andi -
nice word-bending there. I'm asking for pre-existing annotations to survive. It hurts you _nothing_ and it was a world of pain for us to recover those lost annotations. Anyway, if Jeremy does not object to the patch we'll push it in and then rename fastcall to asmcall. Much ado about nothing. Ingo -
I don't have any objections to the idea of the patch, but I'm still
concerned about the practical aspects of it. Maintaining these kinds of
annotations is hard/fragile/etc when the compiler doesn't warn when you
get it wrong, and only a very specific use-case will reveal the problem
Hm, "asmcall" is confusingly close to "asmlinkage" - and they have
exactly the same intent (can be called from asm), but with exactly the
opposite effect. How about something which actually says what we mean.
How about just "regparm"?
J
-
it wont be any different from the situation before - we had no such warnings there either. Anyway, this shouldnt really bother you as at the moment it's only used for -rt. The issue is to keep something we had before (but which was stupidly/carelessly removed). If it breaks we'll yeah, regparm is fine. Ingo -
Until recently (read: before 2.6.20) fastcall had a semantics on i386
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
What I'm objecting to is that you ask for this for your out of tree code without any justification on why exactly -- -pg should in theory work with -mregparms. It's standard policy to require very good reasons for changes that are only useful for out of tree code. People get flamed for this all the time so I'm doing this thankless job here too. Is it just because you didn't want to adapt the tracer for i386 regparm? (that would be an invalid reason in my opinion ;-) The correct fix would be to adapt the tracer then. Or is it because gcc miscompiles something on i386 with -mregparm -pg? (if yes that would be a valid reason, but it should be clearly stated) -Andi -
last i checked it didnt work - i'll re-check that. but even taking the latency tracer completely out of the picture, it's not just for out of tree code - it's to keep the information of the uhm, thank you for such accusations and personal attacks :-( How did i deserve that? Ingo -
earlier gcc versions had problems with -mregparm and with -pg. I just did a quick test with latest gcc and at a quick glance it seems to work better - i'll propagate that throught he whole latency tracer to see whether it's indeed working throughout. Anyway, this means that there's no urgent need for this patch and we've dropped it from the x86 queue for now. As long as it only affects older gcc's it's probably not worth force-keeping the annotations for that purpose alone. Ingo -
I see a point in annotating all C code called from assembler code with
either fastcall or asmlinkage, but how will these annotations be
maintained?
Without anything giving at least a warning these annotations will simply
bitrot.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
It would be really nice if we could get the compiler to warn about
whether mismatches in fastcall use. Without at least a compiler warning
about mismatches between the function pointer type in paravirt_ops and
the actual function, it will almost certainly rot and fail if you
actually need to depend on the annotations.
Hm, so it will still need a fair amount of work to update to the
current kernel and add all the lguest/vmi/xen functions (and presumably
What's trace_special()? Has this escaped from another patch?
J
-
No, there was only that instance in linkage.h and I just got rid of it. Jeff -- Work email - jdike at linux dot intel dot com -
... if you wanted to be *really* anal retentive, you might want to run "make distclean" instead but, from what i've seen so far, i don't think that would change what you're seeing. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca ======================================================================== -
Er... That patch is on top of the current mainline, including commit 2b8232ce512105e28453f301d1510de8363bccd1. Check if what you are applying it against the recent tree. By the look of your build log you are missing - $(Q)ln -fsn $(srctree)/include/asm-$(SUBARCH) include/asm-um/arch + $(Q)ln -fsn $(srctree)/include/asm-$(HEADER_ARCH) include/asm-um/arch else - $(Q)cd $(TOPDIR)/include/asm-um && ln -sf ../asm-$(SUBARCH) arch + $(Q)cd $(TOPDIR)/include/asm-um && ln -sf ../asm-$(HEADER_ARCH) arch in arch/um/Makefile. That, or you simply need to do make mrproper... -
Thanks, Al. You need the patch below in order to get a working UML - feel free to fold it into this. Jeff -- Work email - jdike at linux dot intel dot com KERNEL_DEFINES needs whitespace trimmed, otherwise this whitespace crunching done by make fools the patsubst which is used to remove KERNEL_DEFINES from USER_CFLAGS. Signed-off-by: Jeff Dike <jdike@linux.intel.com> --- arch/um/Makefile | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) Index: linux-2.6/arch/um/Makefile =================================================================== --- linux-2.6.orig/arch/um/Makefile 2007-10-22 16:19:38.000000000 -0400 +++ linux-2.6/arch/um/Makefile 2007-10-22 16:19:44.000000000 -0400 @@ -70,9 +70,12 @@ include $(srctree)/$(ARCH_DIR)/Makefile- # in KBUILD_CFLAGS. Otherwise, it would cause ld to complain about the two different # errnos. # These apply to kernelspace only. +# +# strip leading and trailing whitespace to make the USER_CFLAGS removal of these +# defines more robust -KERNEL_DEFINES = -Derrno=kernel_errno -Dsigprocmask=kernel_sigprocmask \ - -Dmktime=kernel_mktime $(ARCH_KERNEL_DEFINES) +KERNEL_DEFINES = $(strip -Derrno=kernel_errno -Dsigprocmask=kernel_sigprocmask \ + -Dmktime=kernel_mktime $(ARCH_KERNEL_DEFINES)) KBUILD_CFLAGS += $(KERNEL_DEFINES) KBUILD_CFLAGS += $(call cc-option,-fno-unit-at-a-time,) -
Can I get a Signed-off-by: on that? It's not the right fix - the base of the problem is in swap.h, which has this comment: /* only sparc can not include linux/pagemap.h in this file * so leave page_cache_release and release_pages undeclared... */ I poked around a bit for a sparc cross-toolchain, didn't find one, so I couldn't see what exactly the problem was. So, I'll take this fix. Jeff -- Work email - jdike at linux dot intel dot com -
Hi Jeff. Dan Kegel's crosstool builds sparc just fine. And for sparc issues I recommend cc:ing the sparc ML. [Original mail (with patch) is here: http://lkml.org/lkml/2007/10/11/288] Sam -
Prebuilt for Ubuntu 7.04: http://landley.net/code/firmware/downloads/cross-compiler/host-i686/cross-compiler-spa... Source code: Or http://landley.net/code/firmware/downloads/firmware-0.2.2.tar.bz2 For the second one, extract it, cd into it, "./build.sh sparc", and when it finishes your sparc-gcc should be in "build/cross-compiler-sparc/bin". You can move the cross-compiler-sparc directory anywhere you want in the filesystem, and it should still work. Just add the "bin" subdirectory of it to $PATH and CROSS_COMPILE=sparc- Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. -
Thanks - I already got Dan Kegel's crosstools, and they did the trick. What I'd like to do is have linux/swap.h include linux/pagemap.h, but there's this scary comment about that not working on sparc. When I fix this bug "correctly", sparc expodes into a mess of interconnected headers which seem to boil down to sparc including swap.h in pgtable.h when no one else does. The thing is, sparc looks like it's doing things more correctly than anyone else. asm/pgtable.h (i386 and UML, and probably everyone else except sparc) refers to swp_entry_t, which is defined in linux/swap.h, without including swap.h and that's somehow OK. So, from a quick look, it seems like this is a case of our headers being too interconnected and sparc had to opt out in order to do things more correctly. Jeff -- Work email - jdike at linux dot intel dot com -
