On Monday 28 November 2005 05:23, Jeff Dike wrote:
> On Sun, Nov 27, 2005 at 09:59:37PM +0100, Blaisorblade wrote:
> > The attached patch is a (hacky) proposal, alternative to Jeff's
> > fix-stub-syscall6, to fix the SKAS0 compilation problem.
> Bleah :-)
Yep :-).
> > In fact, Jeff's patch makes the problem appear on my system (where I
> > never reproduced it).
> What assembly did you end up with, with my patch?
Actually, looking at it today, it's a different story than the usual one:
====working (from the .s output rather than disassembly):
#APP
push %ebp ; movl %eax,%ebp ; movl $192,%eax ; int $0x80 ; pop %ebp
#NO_APP
movl %eax, %edi
.L4:
movl %edi, -1073745896
#APP
int3
====not-working:
#APP
push %ebp ; movl %eax,%ebp ; movl $192,%eax ; int $0x80 ; pop %ebp
#NO_APP
movl %eax, -16(%ebp)
.L4:
movl -16(%ebp), %eax
movl %eax, -1073745896
#APP
int3
Command line for GCC:
gcc -Wp,-MD,arch/um/kernel/skas/.clone.s.d -Wall -Wundef -Wstrict-prototypes
-Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -O2
-fno-omit-frame-pointer -fno-optimize-sibling-calls -D__arch_um__
-DSUBARCH=\"i386\" -Dvmap=kernel_vmap
-Din6addr_loopback=kernel_in6addr_loopback -Iarch/um/include
-I/home/paolo/Admin/kernel/6/VCS/linux-2.6.14/arch/um/include
-I/home/paolo/Admin/kernel/6/VCS/linux-2.6.14/arch/um/kernel/tt/include
-I/home/paolo/Admin/kernel/6/VCS/linux-2.6.14/arch/um/kernel/skas/include
-D_FILE_OFFSET_BITS=64 -m32 -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -S -o
arch/um/kernel/skas/clone.s
/home/paolo/Admin/kernel/6/VCS/linux-2.6.14/arch/um/kernel/skas/clone.c
As you see, what's moved is the scratch pid location, put in %edi register
normally and in the stack on the faulty assembly (btw, I'm puzzled why GCC
should do this puzzling around).
So, indeed, with your patch GCC understands that the variable is at a known
location, but becomes silly for other reasons.
So, again: can we finally rewrite clone.c in assembly? Or, otherwise, to use a
unique assembly macro joining mmap, the return and trap_myself?
It could be nicer to have it in C, but hey, GCC won, we lost. So let gcc suck
and work without it.
It's fundamentally hacky to get GCC not to use the stack, it's not written for
that. Either you say "ok, let's copy the whole stack content when remapping"
a-la switcheroo() or we agree on ASM.
> > #ifdef CONFIG_MODE_SKAS
> > #define KSTK_REG(tsk, reg) \
> > ({ union uml_pt_regs regs; \
> > get_thread_regs(®s, tsk->thread.mode.skas.switch_buf); \
> > UPT_REG(®s, reg); })
> > #else
> > #define KSTK_REG(tsk, reg) (0xbadbabe)
> > #endif
> Oops, needs fixing.
Btw, the old code was probably uncorrect but didn't crash except for sysrq-t.
Actually, in TT mode we possibly don't have the right location (do we save
the stack pointer before entering the kernel)? Let's just use the old code as
fallback for that, it's not worth implementing such a feature for TT mode.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
