[Mono-dev] Proposed Patch - Google Native Client
vargaz at gmail.com
Fri Jul 2 15:41:48 EDT 2010
I finally managed to read the codegen specific changes, and here are my
- I'd prefer the nacl related changes to be in as few places as possible, so
later changes by
people who don't know nacl won't break nacl support.
There are three places where this is not done:
- x86_prefix - this might be unavoidable
- the calls to nacl_pad_call_reg/call_membase (). Could this be folded
x86_call_reg/x86_call_membase () ?
- places the where code is later patched. I think it would be better to
x86_patch () so it skips the padding added by nacl so these changes are
On Tue, Jun 22, 2010 at 7:29 PM, Elijah Taylor <elijahtaylor at google.com>wrote:
> Greetings Mono Developers,
> Attached is a patch to support 32-bit x86 code generation for Google Native
> Client (http://code.google.com/p/nativeclient/). I encourage you to
> browse our project for more information if you're curious. I apologize for
> the large diff, let me try to explain the highlights to make it easier to
> There is a code generation component (define: __native_client_codegen__)
> which affects the Mono bytecode -> native code generation for x86-32. There
> are a set of alignment restrictions, illegal instructions, and replacement
> instructions we use for Native Client to ensure proper control-flow
> sandboxing. Please see
> http://nativeclient.googlecode.com/svn/data/docs_tarball/nacl/googleclient/native_client/documentation/nacl_paper.pdffor more details.
> There is also a runtime component (define: __native_client__) which
> modifies or disables some functionality to be compatible with the Native
> Client runtime.
> We also had to modify some code that doesn't fall under either of the above
> defines. Most of these changes revolved around type safety. The modified
> version of gcc we use to compile Native Client modules is more strict about
> types, and it caught what look like legitimate issues with the Mono
> codebase. The largest issue in terms of number of errors was the use of
> mono_bool and gboolean interchangeably between declaration and definition of
> many functions. gboolean is defined as an "int" but mono_bool is defined as
> int32_t. Other type issues are listed directly below. Feedback is
> appreciated on these changes because of our unfamiliarity with this code,
> but I modified these in the way that seemed most "right" at the time.
> mono/metadata/decimal.h:47 mono_decimal2string int -> gint32
> mono/metadata/filewatcher.h:28 gboolean -> int
> mono/metadata/filewatcher.c:158 int32 -> gint32
> mono/metadata/threads-type.h:64 int -> gint32
> mono/mini/mini.h:1546 gboolean sort_end -> int sort_type
> mono/mini/mini.h:1733 gboolean fp -> int bank
> The last bit of modification is to genmdesc and the Makefiles in general.
> We added a new flag to genmdesc called "nacl" which overrides the given max
> length of an instruction. Native Client code tends to be larger because of
> some of the instruction requirements we have, so some of the instructions in
> cpu-x86.md had to be modified. This is all tied to a new configure flag
> called "--enable-nacl-codegen", which enables the codegen define, and sets
> up calls to genmdesc with a --nacl flag. It also modifies the mono-wrapper
> script so one aspect of our code generation rules (masking jump targets to
> 32-byte boundaries) is turned off while compiling and testing mono from the
> Makefiles, which is required when testing outside of the Native Client
> environment. We're also including a standalone check "fsacheck" which tests
> mono code generation as full AOT and a the library linked into a fully
> static executable.
> I look forward to your comments, questions, and suggestions.
> -Elijah Taylor
> Google Native Client Team
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list