On Mon, Jan 24, 2005 at 04:16:45PM -0500, Jan Harkes wrote:
>
> Can't find the patch anywhere. I might have deleted it accidentally
> while deleting spam from my inbox.
>
heh - I know the feeling ;) I may be mistaken but I thought I logged it
as a bug/enhancement but, no matter... here is the code:
--- src/process.S.orig 2001-10-05 06:44:08.000000000 +0930
+++ src/process.S
@@ -400,7 +400,83 @@ returnto:
.end returnto
#endif /* mips */
-#ifdef i386
+#if defined(__amd64)
+
+#include <machine/asm.h>
+
+/*
+ savecontext(f, area1, newsp)
+ int (*f)();
+ struct savearea *area1;
+ char *newsp;
+
+ f will be in %rdi
+ *area1 will be in %rsi
+ *newsp will be in %rdx
+*/
+
+ .text
+ENTRY(savecontext)
+ pushq %rsp
+ pushq %rax
+ pushq %rcx
+ pushq %rdx
+ pushq %rbx
+ pushq %rbp
+ pushq %rsi
+ pushq %rdi
+ pushq %r8
+ pushq %r9
+ pushq %r10
+ pushq %r11
+ pushq %r12
+ pushq %r13
+ pushq %r14
+ pushq %r15
+
+ movq %rsp, (%rsi) /* Store sp in savearea. */
+
+ cmpq $0, %rdx /* Check if newsp is NULL */
+ je L1 /* Don't change the stack if newsp is
zero. */
+ movq %rdx, %rsp
+
+L1: xorq %rbp, %rbp /* clear stackframe */
+ call *%rdi /* f(); */
+
+ /* Trigger a segfault, we shouldn't get here anyway. */
+ movq $0, 0
+
+/*
+ returnto(area2)
+ struct savearea *area2;
+
+ area2 will be in %rdi
+*/
+#define area2 8
+
+ENTRY(returnto)
+ mov (%rdi), %rsp /* Restore stack pointer. */
+ popq %r15
+ popq %r14
+ popq %r13
+ popq %r12
+ popq %r11
+ popq %r10
+ popq %r9
+ popq %r8
+ popq %rdi
+ popq %rsi
+ popq %rbp
+ popq %rbx
+ popq %rdx
+ popq %rcx
+ popq %rax
+ popq %rsp
+ ret
+
+#endif /* amd64 */
+
+#if defined(i386)
/*
savecontext(f, area1, newsp)
*snip*snip*snip*
> It actually seems to work now and it should be more portable.
>
Hmmmm would it not be better to use pthreads instead? Most, if not all,
OS's these days have or can have a libpthread which makes the code even
more portable...
>
> It is probably something with the marshalling/unmarshalling, where we
> stick a 64-bit value in the outgoing packet buffer, but then only
> increment by 4 bytes, so we end up losing half of the original
> information and when unpacking we end up copying the overwritten part
> back. This should be solvable by forcing RPC2_Integer to be a 32-bit
> integer instead of the current (64-bit) long.
>
ok - that sounds like fun (not). I was looking at coda and cleaning up
some of the warnings there, mainly trying to use longs to store pointers
which does not work well in 64 bit land :) I suppose I should bash on rpc2
for a while and see what I can do/damage ;)
--
Brett Lymn
