From: Jeff D. <jd...@ka...> - 2002-01-31 16:54:48
|
sub...@ya... said: > Am I correct in assuming that for powerpc I need to reverse the byte > order so that > n1 = stack1[i] << 24 | (stack1[i + 1] << 16) | > (stack1[i + 2] << 8) | stack1[i + 3] ; > Similarly for n2. Yes, if ppc words have their bytes in reverse order compared to i386. md...@de... said: > This seems overcomplicated...if it is in host byte order, why not just > memcpy it straight into n1 and n2? Or if it is guaranteed to be > properly aligned, just cast the pointer and do an assignment? Yeah, memcpy would work and would make that more portable. I guess that didn't occur to me. I'm not making assumptions about alignment. Jeff |
From: McMechan, J. <McM...@na...> - 2002-02-01 01:06:36
|
Is there some special reason not to do this with the equivalent cast op like n1 = *((long *)&stack1[i]); n2 = *((long *)&stack2[i]); this is much easier for the compiler to optimize down to a load. and also does not require byte order or word length dependency. if it is a generic pointer something like n1= *((void **)&stack1[i]); n1= *((void **)&stack2[i]); might be better I just tried it and it booted single user for me but how is this section exercised? What is the status of the PPC port I don't recall seeing much recently. I found that the ubd.c COW logic is not yet big endian portable in that it uses long[] as a big bitmap --- uml-2.4.17-10/arch/um/kernel/process_kern.c Thu Jan 31 16:30:34 2002 +++ work-2.4.17-10/arch/um/kernel/process_kern.c Thu Jan 31 16:59:44 2002 @@ -639,11 +639,8 @@ } memset(mask, 0, size); for(i = PAGE_SIZE - size; i < PAGE_SIZE - sizeof(void *); i++){ - /* This is horribly word-length- and byte-order-dependent */ - n1 = stack1[i] | (stack1[i + 1] << 8) | - (stack1[i + 2] << 16) | stack1[i + 3] << 24; - n2 = stack2[i] | (stack2[i + 1] << 8) | - (stack2[i + 2] << 16) | stack2[i + 3] << 24; + n1 = *((void **) &stack1[i]); + n2 = *((void **) &stack2[i]); /* Internal pointers have to be different on different * stacks, and they have to point to the stack page. If not, |
From: Subhachandra C. <sub...@ya...> - 2002-02-01 01:45:42
|
> Is there some special reason not to do this with the > equivalent cast op like > > n1 = *((long *)&stack1[i]); > n2 = *((long *)&stack2[i]); Will that work if the address is not word aligned? I will check it out though. That was the concern I had when I was thinking about changing the current implementation. The other suggestion about using memcpy() might bet better if there are alignment problems. I think diff_stacks comes into play while creating new processes. I will have to understand this code better. About the status of the ppc port, I am trying to get the 2.4.14 kernel working. I had to do a couple of minor fixes to get the code to compile. Then I have been trying to get the kernel to do atleast single user boot. It seems to either hang or crash right when it finishes processing rc.sysinit. I suspect at some popint after that it is trying to spawn a process and runs into trouble. In its current state COW code is not a problem as I can use a fresh ramdisk each time. Subhachandra --- "McMechan, James" <McM...@na...> wrote: > Is there some special reason not to do this with the > equivalent cast op like > > n1 = *((long *)&stack1[i]); > n2 = *((long *)&stack2[i]); > > this is much easier for the compiler to optimize > down to a load. > and also does not require byte order or word length > dependency. > if it is a generic pointer something like > > n1= *((void **)&stack1[i]); > n1= *((void **)&stack2[i]); > > might be better I just tried it and it booted single > user for me but how is > this section exercised? > > What is the status of the PPC port I don't recall > seeing much recently. > I found that the ubd.c COW logic is not yet big > endian portable in that it > uses long[] as a big bitmap > > > --- uml-2.4.17-10/arch/um/kernel/process_kern.c Thu > Jan 31 16:30:34 2002 > +++ work-2.4.17-10/arch/um/kernel/process_kern.c > Thu Jan 31 16:59:44 > 2002 > @@ -639,11 +639,8 @@ > } > memset(mask, 0, size); > for(i = PAGE_SIZE - size; i < PAGE_SIZE - > sizeof(void *); i++){ > - /* This is horribly word-length- > and byte-order-dependent */ > - n1 = stack1[i] | (stack1[i + 1] << > 8) | > - (stack1[i + 2] << 16) | > stack1[i + 3] << 24; > - n2 = stack2[i] | (stack2[i + 1] << > 8) | > - (stack2[i + 2] << 16) | > stack2[i + 3] << 24; > + n1 = *((void **) &stack1[i]); > + n2 = *((void **) &stack2[i]); > > /* Internal pointers have to be > different on different > * stacks, and they have to point > to the stack page. If > not, > > _______________________________________________ > User-mode-linux-devel mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com |
From: Matt Z. <md...@de...> - 2002-02-01 02:13:27
|
On Thu, Jan 31, 2002 at 05:05:11PM -0800, McMechan, James wrote: > Is there some special reason not to do this with the equivalent cast op like > > n1 = *((long *)&stack1[i]); > n2 = *((long *)&stack2[i]); Because that will fail if the value is not word-aligned. > this is much easier for the compiler to optimize down to a load. and also > does not require byte order or word length dependency. In gcc, memcpy and friends are special builtins in order to make this kind of optimization both fast and portable. -- - mdz |
From: Jeff D. <jd...@ka...> - 2002-02-01 01:50:21
|
McM...@na... said: > Is there some special reason not to do this with the equivalent cast > op like > n1 = *((long *)&stack1[i]); > n2 = *((long *)&stack2[i]); Yeah, that's wrong. I want the word consisting of the bytes 0, 1, 2, 3 (say). On x86, *((long *)&stack1[0] will give that to me. On ppc, *((long *)&stack1[0] will give me the word consisting of the bytes 0, -1, -2, -3, I think. Jeff |
From: Jeff D. <jd...@ka...> - 2002-02-01 05:25:47
|
sub...@ya... said: > I think diff_stacks comes into play while creating new processes. I > will have to understand this code better. No, it's used (rather, its results are used) during signal delivery. What I am attempting to do there is create a relocatable stack frame that can be used to deliver signals to processes. Two close-to-identical frames are created and given to diff_stacks. Any differences between the two must be due to frame pointers or other internal stack references, and must be adjusted when the frame is copied onto the process stack. It's a mess, and I'm thinking about ways of getting rid of it. > About the status of the ppc port, I am trying to get the 2.4.14 kernel > working. I had to do a couple of minor fixes to get the code to > compile. Send patches for what you've done so far... > Then I have been trying to get the kernel to do atleast > single user boot. It seems to either hang or crash right when it > finishes processing rc.sysinit. If UML dies as a process exits, then that would implicate this code because that's when a SIGCHLD will be delivered. Jeff |
From: Subhachandra C. <sub...@ya...> - 2002-02-06 07:21:20
|
diff -Naur linux-2.4.14-orig/arch/um/kernel/sys_call_table.c linux-2.4.14/arch/um/kernel/sys_call_table.c --- linux-2.4.14-orig/arch/um/kernel/sys_call_table.c Tue Feb 5 18:09:07 2002+++ linux-2.4.14/arch/um/kernel/sys_call_table.c Sun Nov 11 18:54:03 2001@@ -436,7 +436,7 @@ [ __NR_fstat64 ] = sys_fstat64, [ __NR_fcntl64 ] = sys_fcntl64, [ __NR_getdents64 ] = sys_getdents64, - [ __NR_security ] = sys_ni_syscall, +/* [ __NR_security ] = sys_ni_syscall, */ [ __NR_gettid ] = sys_gettid, [ __NR_readahead ] = sys_readahead, ARCH_SYSCALLS diff -Naur linux-2.4.14-orig/arch/um/sys-ppc/sigcontext.c linux-2.4.14/arch/um/sys-ppc/sigcontext.c --- linux-2.4.14-orig/arch/um/sys-ppc/sigcontext.c Tue Feb 5 18:09:08 2002+++ linux-2.4.14/arch/um/sys-ppc/sigcontext.c Sun Nov 11 21:50:56 2001 @@ -38,7 +38,9 @@ sc = sc_ptr; // FIXME: need to investigate what's going on with struct pt_regs etc. - *regs = *(sc->regs); + + memcpy(regs,sc->regs,sizeof(struct sys_pt_regs)); +// *regs = *(sc->regs); } /* __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com |