[Mono-dev] Proposed Patch - Google Native Client

Rafael Teixeira monoman at gmail.com
Fri Jun 25 11:31:55 EDT 2010

Looks promising, thanks for the effort, and specially the stricter checks
result summary.

Rafael "Monoman" Teixeira
"To be creative means to be in love with life. You can be creative only if
you love life enough that you want to enhance its beauty, you want to bring
a little more music to it, a little more poetry to it, a little more dance
to it."

On Tue, Jun 22, 2010 at 2: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
> digest.
> 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
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100625/d8b3eee7/attachment.html 

More information about the Mono-devel-list mailing list