[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [PATCH] caml-stubdom: fix "red zone" bug


  • To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Patrick Colp <pjcolp@xxxxxxxxx>
  • Date: Tue, 26 Oct 2010 10:44:04 -0700
  • Delivery-date: Tue, 26 Oct 2010 10:44:45 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

According to the AMD64 ABI, the 128-byte area below %rsp is reserved
for scratch space and should not be used by signal, interrupt, or
exception handlers. However, Mini-OS does not adhere to this
interface. As a result, the -mno-red-zone flag must be provided to gcc
in order to force code to be compiled without this assumption. In the
case of the c-stubdom or the ioemu stubdom, Makefile configuration and
flags are inherited from Xen, which includes this flag. However, in
the case of the ocaml stubdom, since an independent ocaml version is
pulled and compiled, with its own make system in place, this flag is
not present.

As a default optimisation (no optimisation flags specified), gcc
generates function header code that uses mov instead of push (to save
a few instructions). However, with the 128-byte scratch space
assumption in place, registers are moved onto the stack *before* %rsp
is updated. This results in cases where when a function is being
called, *after* the first mov <foo>, <offset>(%rsp) but *before* the
%rsp update, sub <bar>, %rsp, if an interrupt is fired, then the stack
will be clobbered (as Mini-OS uses the application stack for its
stack, pushing registers onto the stack on entry and popping them off
on exit).

This patch fixes this issue by passing the -mno-red-zone flag to the
ocaml configure script in the stubdom Makefile.


Signed-off-by: Patrick Colp <pjcolp@xxxxxxxxx>

Attachment: stubdom_caml_fix_red_zone_bug.patch
Description: Text Data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.