Re: [Mono-dev] [PATCH] more support for Google Native Client
Hi,
I merged your changes to mono's master except for the following:
runtime/mono-wrapper.in
mono/mini/genmdesc.c
nacl/
Zoltan
On Thu, Jan 6, 2011 at 2:22 AM, Elijah Taylor elijahtay...@google.comwrote:
Ok, I'll check out the changes/info you mentioned and go through the files
that auto-merged, too. Probably won't get this done for at least a day or
so, but I'll rebase again once I've fixed it. Hopefully by that point
something else won't have broken too :)
-Elijah
On Wed, Jan 5, 2011 at 5:19 PM, Zoltan Varga var...@gmail.com wrote:
Hi,
This should work as follows: every aot image contains a MonoAotFileInfo
structure,
emitted in emit_file_info () in aot-compiler.c, which has a 'flags'
field, and the MONO_AOT_FILE_FLAG_FULL_AOT flag should be set in
this field. At runtime, check_usable() in aot-runtime.c checks this flag.
Zoltan
On Thu, Jan 6, 2011 at 2:10 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
On Thu, Jan 6, 2011 at 1:24 AM, Elijah Taylor
elijahtay...@google.comwrote:
Zoltan,
I've rebased from mono's master branch and fixed all merge conflicts,
but something that's gone in since I first forked has now broken NaCl AOT
compilation for me. On amd64 the compiler just crashes and I'm looking
into
that, nut on x86 I'm getting this: Can't use AOT image 'mscorlib' in
aot-only mode because it is not compiled with --aot=full. But I'm
compiling with --aot=full,static,nodebug,ntrampolines=4096
If need be I can pick through the AOT changes that have gone in, but I
was hoping you or someone on this list would be able to tell me the major
changes to AOT from the past 3 weeks and some ideas about what might be
getting in my way. Can you shed any light?
There was a big reorganization in the AOT file format to reduce the
number of global symbols exported from the aot images. No idea why this is
causing problems. make fullaotcheck and make fsacheck still seems to work
for me on x86. I fixed a uninitilized memory error in 88d676ffd425def3,
maybe that will help.
Zoltan
-Elijah
On Wed, Jan 5, 2011 at 3:51 PM, Zoltan Varga var...@gmail.com wrote:
Hi,
I think the current code looks ok, and we should think about how to
merge it into mono trunk. As a first step, could you rebase your master
branch on top of master to fix the few conflicts which has surfaced due to
changes to mono master ?
Zoltan
On Wed, Jan 5, 2011 at 8:23 PM, Elijah Taylor elijahtay...@google.com
wrote:
Hi Zoltan,
I've addressed all of the issues you pointed out (minus genmdesc.c:
__nacl_suspend_thread_if_needed, but that doesn't need to be merged in at
this time, it can remain in my local repository only). Please take
another
look at your earliest convenience and let me know if there's anything
else
you need from me.
-Elijah
On Tue, Jan 4, 2011 at 10:55 AM, Elijah Taylor
elijahtay...@google.com wrote:
Replies inline:
On Tue, Jan 4, 2011 at 10:30 AM, Zoltan Varga var...@gmail.comwrote:
Hi,
Some comments:
- the patch changes IMT_REG to AMD64_R11 in the non-nacl case, I'm
not sure thats
intentional.
Has this changed in the last six months on the Mono side? IIRC I
didn't mean to change anything like this. The reason I made explicit
defines was so code in aot-compiler and mini-amd64 could share defines
over
which reg was the one we jump through and which was a scratch reg. I'll
diff vs Mono head revision and make it correct.
- you could define __mono_ilp32__ in the nacl/amd64 case, and use
that instead of
defined(__native_client_codegen__) defined(TARGET_AMD64) in a
few places.
That sounds reasonable. I'm assuming you mean non-arch specific
areas like mini.c, aot-*.c, method-to-ir.c, etc? Are there any other
major
consequences to defining __mono_ilp32__ ?
- it would be better to define nacl_global_codeman_validate () as a
no-op in the non-nacl case, so its callers wouldn't need #ifdefs.
I'll fix this.
- genmdesc.c contains this change, which is probably not needed:
+void __nacl_suspend_thread_if_needed() {}
+
It is needed temporarily due to a preliminary GC implementation, we
don't have to submit it this way. Eventually (soon) we won't need it at
all.
- you could use sizeof(mgreg_t) instead of SIZEOF_REGISTER to be
consistent with
the usage of sizeof(gpointer).
Sounds good. I'll try to use sizeof for all compiled code and only
use SIZEOF_REGISTER/SIZEOF_VOID_P for pre-processor directives only.
Other than these, I think the changes look fine, they aren't that
disruptive, since they don't
change the non-nacl behavior at all.
Great! I was worried just based on LOC changed that it might get
more resistance. In truth I'm more worried about future Mono changes
accidentally breaking NaCl behavior. I'm planning on getting some
automated
testing implemented soon to
Re: [Mono-dev] [PATCH] more support for Google Native Client
Hi,
I had to revert this change, as it was causing crashes on amd64:
@@ -357,8 +494,10 @@ mono_code_manager_reserve_align (MonoCodeManager *cman,
int size, int alignment)
for (chunk = cman-current; chunk; chunk = chunk-next) {
if (ALIGN_INT (chunk-pos, alignment) + size = chunk-size) {
chunk-pos = ALIGN_INT (chunk-pos, alignment);
- ptr = chunk-data + chunk-pos;
- chunk-pos += size;
+ /* Align the chunk-data we add to chunk-pos */
+ /* or we can't guarantee proper alignment */
+ ptr = (void*)uintptr_t)chunk-data + align_mask) ~align_mask) +
chunk-pos);
+ chunk-pos = ((char*)ptr - chunk-data) + size;
return ptr;
}
}
it was inside a #ifndef native_client, so why is this needed ?
Zoltan
On Thu, Jan 6, 2011 at 11:34 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
I merged your changes to mono's master except for the following:
runtime/mono-wrapper.in
mono/mini/genmdesc.c
nacl/
Zoltan
On Thu, Jan 6, 2011 at 2:22 AM, Elijah Taylor elijahtay...@google.comwrote:
Ok, I'll check out the changes/info you mentioned and go through the files
that auto-merged, too. Probably won't get this done for at least a day or
so, but I'll rebase again once I've fixed it. Hopefully by that point
something else won't have broken too :)
-Elijah
On Wed, Jan 5, 2011 at 5:19 PM, Zoltan Varga var...@gmail.com wrote:
Hi,
This should work as follows: every aot image contains a MonoAotFileInfo
structure,
emitted in emit_file_info () in aot-compiler.c, which has a 'flags'
field, and the MONO_AOT_FILE_FLAG_FULL_AOT flag should be set in
this field. At runtime, check_usable() in aot-runtime.c checks this flag.
Zoltan
On Thu, Jan 6, 2011 at 2:10 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
On Thu, Jan 6, 2011 at 1:24 AM, Elijah Taylor
elijahtay...@google.comwrote:
Zoltan,
I've rebased from mono's master branch and fixed all merge conflicts,
but something that's gone in since I first forked has now broken NaCl AOT
compilation for me. On amd64 the compiler just crashes and I'm looking
into
that, nut on x86 I'm getting this: Can't use AOT image 'mscorlib' in
aot-only mode because it is not compiled with --aot=full. But I'm
compiling with --aot=full,static,nodebug,ntrampolines=4096
If need be I can pick through the AOT changes that have gone in, but I
was hoping you or someone on this list would be able to tell me the major
changes to AOT from the past 3 weeks and some ideas about what might be
getting in my way. Can you shed any light?
There was a big reorganization in the AOT file format to reduce the
number of global symbols exported from the aot images. No idea why this is
causing problems. make fullaotcheck and make fsacheck still seems to work
for me on x86. I fixed a uninitilized memory error in 88d676ffd425def3,
maybe that will help.
Zoltan
-Elijah
On Wed, Jan 5, 2011 at 3:51 PM, Zoltan Varga var...@gmail.com wrote:
Hi,
I think the current code looks ok, and we should think about how to
merge it into mono trunk. As a first step, could you rebase your master
branch on top of master to fix the few conflicts which has surfaced due
to
changes to mono master ?
Zoltan
On Wed, Jan 5, 2011 at 8:23 PM, Elijah Taylor
elijahtay...@google.com wrote:
Hi Zoltan,
I've addressed all of the issues you pointed out (minus genmdesc.c:
__nacl_suspend_thread_if_needed, but that doesn't need to be merged in
at
this time, it can remain in my local repository only). Please take
another
look at your earliest convenience and let me know if there's anything
else
you need from me.
-Elijah
On Tue, Jan 4, 2011 at 10:55 AM, Elijah Taylor
elijahtay...@google.com wrote:
Replies inline:
On Tue, Jan 4, 2011 at 10:30 AM, Zoltan Varga var...@gmail.comwrote:
Hi,
Some comments:
- the patch changes IMT_REG to AMD64_R11 in the non-nacl case, I'm
not sure thats
intentional.
Has this changed in the last six months on the Mono side? IIRC I
didn't mean to change anything like this. The reason I made explicit
defines was so code in aot-compiler and mini-amd64 could share defines
over
which reg was the one we jump through and which was a scratch reg.
I'll
diff vs Mono head revision and make it correct.
- you could define __mono_ilp32__ in the nacl/amd64 case, and use
that instead of
defined(__native_client_codegen__) defined(TARGET_AMD64) in a
few places.
That sounds reasonable. I'm assuming you mean non-arch specific
areas like mini.c, aot-*.c, method-to-ir.c, etc? Are there any other
major
consequences to defining __mono_ilp32__ ?
- it would be better to define nacl_global_codeman_validate () as a
no-op in the non-nacl case, so its callers wouldn't need #ifdefs.
I'll fix this.
- genmdesc.c contains this change, which is probably not needed:
+void
Re: [Mono-dev] File not found error when using Activator.CreateInstanceFrom()
On Wed, Jan 5, 2011 at 8:04 PM, mike mgu...@knology.net wrote: Not sure what you mean. Actually, I was just refreshing the thread. ;-) See previous post and example code, If I p/Invoke to a single native dll, all is fine. However if that dll depends on a secondary native dll, I get an unhandled exception: System.DLLNotFoundException. Again, this scenario works fine under .NET, fails under 2.8 (under win mono) The issue seems to be related to p/Invoking a dynamic link library which depends on a second native dll. Have you checked your LD_LIBRARY_PATH environment variable ? In order to find a native library in the current folder, the LD_LIBRARY_PATH must contain . or the full path to your application's folder. This vary from windows which is searching in the application's base folder first (see Remarks in http://msdn.microsoft.com/en-us/library/ms684175(v=vs.85).aspx) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Git line-ending issues
Hi guys, I'm having issues with a commit I did (d'oh :(), and would like help to clean up my mess. The commit can be seen here: https://github.com/mono/mono/commit/4d5451a61ce63769083ebad3b1a5d9055a27b6df I only removed a few lines in the file, but the whole file shows up as changed. From what I understand, this is due to a difference in line-ending encoding. Looking at the .gitattributes file in the same folder, I see certain files (including the one I modified) are specified as having a certain line-ending encoding (CRLF). 1- What is the best way to fix my problem? Simply remove the concerned line from the .gitattributes file, or remodify the file I changed? 2- In general, should we use CRLF or not? Do we want to gradually homogenize things and apply the same logic for all files, and if so, what type of line ending should we use? Or should we leave everything as is? Thanks in advance, and sorry for being a noob. -- View this message in context: http://mono.1490590.n4.nabble.com/Git-line-ending-issues-tp3177991p3177991.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] more support for Google Native Client
This bit of code runs for our AOT compiler, but not for our JIT (in that
case, it's a native 32-bit app that defines __native_client_codegen__).
The problem is that chunk-data isn't guaranteed to be aligned to MIN_ALIGN
**or** the alignment you pass into *mono_code_manager_reserve_align* if you
use mono_valloc instead of dlmemalign in *new_codechunk*. But chunk-pos is
aligned to the alignment passed in, so the returned pointer could be
misaligned.
As you can see in the alloc function I adjusted it to give MIN_ALIGN - 1
extra bytes to account for this slop, and there's an identical piece to this
below for new codechunks that are allocated. I'm curious why this is
causing problems for non-nacl builds... if chunk-data is aligned this
should essentially be a no-op, and if it's not aligned, this code is
supposed to fix that. Is there a simple test I can run to see the failure?
On Thu, Jan 6, 2011 at 3:43 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
I had to revert this change, as it was causing crashes on amd64:
@@ -357,8 +494,10 @@ mono_code_manager_reserve_align (MonoCodeManager
*cman, int size, int alignment)
for (chunk = cman-current; chunk; chunk = chunk-next) {
if (ALIGN_INT (chunk-pos, alignment) + size = chunk-size) {
chunk-pos = ALIGN_INT (chunk-pos, alignment);
- ptr = chunk-data + chunk-pos;
- chunk-pos += size;
+ /* Align the chunk-data we add to chunk-pos */
+ /* or we can't guarantee proper alignment */
+ ptr = (void*)uintptr_t)chunk-data + align_mask) ~align_mask) +
chunk-pos);
+ chunk-pos = ((char*)ptr - chunk-data) + size;
return ptr;
}
}
it was inside a #ifndef native_client, so why is this needed ?
Zoltan
On Thu, Jan 6, 2011 at 11:34 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
I merged your changes to mono's master except for the following:
runtime/mono-wrapper.in
mono/mini/genmdesc.c
nacl/
Zoltan
On Thu, Jan 6, 2011 at 2:22 AM, Elijah Taylor elijahtay...@google.comwrote:
Ok, I'll check out the changes/info you mentioned and go through the
files that auto-merged, too. Probably won't get this done for at least a
day or so, but I'll rebase again once I've fixed it. Hopefully by that
point something else won't have broken too :)
-Elijah
On Wed, Jan 5, 2011 at 5:19 PM, Zoltan Varga var...@gmail.com wrote:
Hi,
This should work as follows: every aot image contains a
MonoAotFileInfo structure,
emitted in emit_file_info () in aot-compiler.c, which has a 'flags'
field, and the MONO_AOT_FILE_FLAG_FULL_AOT flag should be set in
this field. At runtime, check_usable() in aot-runtime.c checks this
flag.
Zoltan
On Thu, Jan 6, 2011 at 2:10 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
On Thu, Jan 6, 2011 at 1:24 AM, Elijah Taylor elijahtay...@google.com
wrote:
Zoltan,
I've rebased from mono's master branch and fixed all merge conflicts,
but something that's gone in since I first forked has now broken NaCl AOT
compilation for me. On amd64 the compiler just crashes and I'm looking
into
that, nut on x86 I'm getting this: Can't use AOT image 'mscorlib' in
aot-only mode because it is not compiled with --aot=full. But I'm
compiling with --aot=full,static,nodebug,ntrampolines=4096
If need be I can pick through the AOT changes that have gone in, but I
was hoping you or someone on this list would be able to tell me the major
changes to AOT from the past 3 weeks and some ideas about what might be
getting in my way. Can you shed any light?
There was a big reorganization in the AOT file format to reduce the
number of global symbols exported from the aot images. No idea why this is
causing problems. make fullaotcheck and make fsacheck still seems to work
for me on x86. I fixed a uninitilized memory error in 88d676ffd425def3,
maybe that will help.
Zoltan
-Elijah
On Wed, Jan 5, 2011 at 3:51 PM, Zoltan Varga var...@gmail.comwrote:
Hi,
I think the current code looks ok, and we should think about how to
merge it into mono trunk. As a first step, could you rebase your master
branch on top of master to fix the few conflicts which has surfaced due
to
changes to mono master ?
Zoltan
On Wed, Jan 5, 2011 at 8:23 PM, Elijah Taylor
elijahtay...@google.com wrote:
Hi Zoltan,
I've addressed all of the issues you pointed out (minus genmdesc.c:
__nacl_suspend_thread_if_needed, but that doesn't need to be merged in
at
this time, it can remain in my local repository only). Please take
another
look at your earliest convenience and let me know if there's anything
else
you need from me.
-Elijah
On Tue, Jan 4, 2011 at 10:55 AM, Elijah Taylor
elijahtay...@google.com wrote:
Replies inline:
On Tue, Jan 4, 2011 at 10:30 AM, Zoltan Varga var...@gmail.comwrote:
Hi,
Some comments:
- the patch changes IMT_REG to AMD64_R11 in the non-nacl
Re: [Mono-dev] [PATCH] more support for Google Native Client
Hi,
Its fixed now, it was missing a (uintptr_t) cast around align_mask.
mono_valloc () is supposed to return pagesize aligned memory, isn't that
enough ?
Zoltan
On Thu, Jan 6, 2011 at 8:14 PM, Elijah Taylor elijahtay...@google.comwrote:
This bit of code runs for our AOT compiler, but not for our JIT (in that
case, it's a native 32-bit app that defines __native_client_codegen__).
The problem is that chunk-data isn't guaranteed to be aligned to MIN_ALIGN
**or** the alignment you pass into *mono_code_manager_reserve_align* if
you use mono_valloc instead of dlmemalign in *new_codechunk*. But
chunk-pos is aligned to the alignment passed in, so the returned pointer
could be misaligned.
As you can see in the alloc function I adjusted it to give MIN_ALIGN - 1
extra bytes to account for this slop, and there's an identical piece to this
below for new codechunks that are allocated. I'm curious why this is
causing problems for non-nacl builds... if chunk-data is aligned this
should essentially be a no-op, and if it's not aligned, this code is
supposed to fix that. Is there a simple test I can run to see the failure?
On Thu, Jan 6, 2011 at 3:43 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
I had to revert this change, as it was causing crashes on amd64:
@@ -357,8 +494,10 @@ mono_code_manager_reserve_align (MonoCodeManager
*cman, int size, int alignment)
for (chunk = cman-current; chunk; chunk = chunk-next) {
if (ALIGN_INT (chunk-pos, alignment) + size = chunk-size) {
chunk-pos = ALIGN_INT (chunk-pos, alignment);
- ptr = chunk-data + chunk-pos;
- chunk-pos += size;
+ /* Align the chunk-data we add to chunk-pos */
+ /* or we can't guarantee proper alignment */
+ ptr = (void*)uintptr_t)chunk-data + align_mask) ~align_mask) +
chunk-pos);
+ chunk-pos = ((char*)ptr - chunk-data) + size;
return ptr;
}
}
it was inside a #ifndef native_client, so why is this needed ?
Zoltan
On Thu, Jan 6, 2011 at 11:34 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
I merged your changes to mono's master except for the following:
runtime/mono-wrapper.in
mono/mini/genmdesc.c
nacl/
Zoltan
On Thu, Jan 6, 2011 at 2:22 AM, Elijah Taylor
elijahtay...@google.comwrote:
Ok, I'll check out the changes/info you mentioned and go through the
files that auto-merged, too. Probably won't get this done for at least a
day or so, but I'll rebase again once I've fixed it. Hopefully by that
point something else won't have broken too :)
-Elijah
On Wed, Jan 5, 2011 at 5:19 PM, Zoltan Varga var...@gmail.com wrote:
Hi,
This should work as follows: every aot image contains a
MonoAotFileInfo structure,
emitted in emit_file_info () in aot-compiler.c, which has a 'flags'
field, and the MONO_AOT_FILE_FLAG_FULL_AOT flag should be set in
this field. At runtime, check_usable() in aot-runtime.c checks this
flag.
Zoltan
On Thu, Jan 6, 2011 at 2:10 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
On Thu, Jan 6, 2011 at 1:24 AM, Elijah Taylor
elijahtay...@google.com wrote:
Zoltan,
I've rebased from mono's master branch and fixed all merge conflicts,
but something that's gone in since I first forked has now broken NaCl
AOT
compilation for me. On amd64 the compiler just crashes and I'm looking
into
that, nut on x86 I'm getting this: Can't use AOT image 'mscorlib' in
aot-only mode because it is not compiled with --aot=full. But I'm
compiling with --aot=full,static,nodebug,ntrampolines=4096
If need be I can pick through the AOT changes that have gone in, but
I was hoping you or someone on this list would be able to tell me the
major
changes to AOT from the past 3 weeks and some ideas about what might be
getting in my way. Can you shed any light?
There was a big reorganization in the AOT file format to reduce the
number of global symbols exported from the aot images. No idea why this
is
causing problems. make fullaotcheck and make fsacheck still seems to work
for me on x86. I fixed a uninitilized memory error in 88d676ffd425def3,
maybe that will help.
Zoltan
-Elijah
On Wed, Jan 5, 2011 at 3:51 PM, Zoltan Varga var...@gmail.comwrote:
Hi,
I think the current code looks ok, and we should think about how
to merge it into mono trunk. As a first step, could you rebase your
master
branch on top of master to fix the few conflicts which has surfaced
due to
changes to mono master ?
Zoltan
On Wed, Jan 5, 2011 at 8:23 PM, Elijah Taylor
elijahtay...@google.com wrote:
Hi Zoltan,
I've addressed all of the issues you pointed out (minus genmdesc.c:
__nacl_suspend_thread_if_needed, but that doesn't need to be merged
in at
this time, it can remain in my local repository only). Please take
another
look at your earliest convenience and let me know if there's anything
else
Re: [Mono-dev] Git line-ending issues
On Thu, Jan 6, 2011 at 2:02 PM, Stifu st...@free.fr wrote: Hi guys, I'm having issues with a commit I did (d'oh :(), and would like help to clean up my mess. The commit can be seen here: https://github.com/mono/mono/commit/4d5451a61ce63769083ebad3b1a5d9055a27b6df I only removed a few lines in the file, but the whole file shows up as changed. From what I understand, this is due to a difference in line-ending encoding. Looking at the .gitattributes file in the same folder, I see certain files (including the one I modified) are specified as having a certain line-ending encoding (CRLF). The .gitattributes format is rather unintuitive. crlf means the file is stored as lf in the repo, but converted to/from crlf on windows. -crlf explicitly disables conversions, in case the user has autoconversion enabled for all files. Are you perhaps using a git tools that ignores these attributes? -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] more support for Google Native Client
Page alignment would be good enough, but I wasn't clear because I had
forgotten some details. When I saw this behavior we were using the dummy
implementation of mono_valloc which falls back on malloc, which I don't
believe we use anymore for the AOT compiler since it's a native app.
This code is probably not necessary for NaCl anymore, but if anyone is using
this dummy implementation then it's still a valid fix.
On Thu, Jan 6, 2011 at 11:31 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
Its fixed now, it was missing a (uintptr_t) cast around align_mask.
mono_valloc () is supposed to return pagesize aligned memory, isn't that
enough ?
Zoltan
On Thu, Jan 6, 2011 at 8:14 PM, Elijah Taylor elijahtay...@google.comwrote:
This bit of code runs for our AOT compiler, but not for our JIT (in that
case, it's a native 32-bit app that defines __native_client_codegen__).
The problem is that chunk-data isn't guaranteed to be aligned to
MIN_ALIGN **or** the alignment you pass into *
mono_code_manager_reserve_align* if you use mono_valloc instead of
dlmemalign in *new_codechunk*. But chunk-pos is aligned to the
alignment passed in, so the returned pointer could be misaligned.
As you can see in the alloc function I adjusted it to give MIN_ALIGN - 1
extra bytes to account for this slop, and there's an identical piece to this
below for new codechunks that are allocated. I'm curious why this is
causing problems for non-nacl builds... if chunk-data is aligned this
should essentially be a no-op, and if it's not aligned, this code is
supposed to fix that. Is there a simple test I can run to see the failure?
On Thu, Jan 6, 2011 at 3:43 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
I had to revert this change, as it was causing crashes on amd64:
@@ -357,8 +494,10 @@ mono_code_manager_reserve_align (MonoCodeManager
*cman, int size, int alignment)
for (chunk = cman-current; chunk; chunk = chunk-next) {
if (ALIGN_INT (chunk-pos, alignment) + size = chunk-size) {
chunk-pos = ALIGN_INT (chunk-pos, alignment);
- ptr = chunk-data + chunk-pos;
- chunk-pos += size;
+ /* Align the chunk-data we add to chunk-pos */
+ /* or we can't guarantee proper alignment */
+ ptr = (void*)uintptr_t)chunk-data + align_mask) ~align_mask) +
chunk-pos);
+ chunk-pos = ((char*)ptr - chunk-data) + size;
return ptr;
}
}
it was inside a #ifndef native_client, so why is this needed ?
Zoltan
On Thu, Jan 6, 2011 at 11:34 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
I merged your changes to mono's master except for the following:
runtime/mono-wrapper.in
mono/mini/genmdesc.c
nacl/
Zoltan
On Thu, Jan 6, 2011 at 2:22 AM, Elijah Taylor
elijahtay...@google.comwrote:
Ok, I'll check out the changes/info you mentioned and go through the
files that auto-merged, too. Probably won't get this done for at least a
day or so, but I'll rebase again once I've fixed it. Hopefully by that
point something else won't have broken too :)
-Elijah
On Wed, Jan 5, 2011 at 5:19 PM, Zoltan Varga var...@gmail.com wrote:
Hi,
This should work as follows: every aot image contains a
MonoAotFileInfo structure,
emitted in emit_file_info () in aot-compiler.c, which has a 'flags'
field, and the MONO_AOT_FILE_FLAG_FULL_AOT flag should be set in
this field. At runtime, check_usable() in aot-runtime.c checks this
flag.
Zoltan
On Thu, Jan 6, 2011 at 2:10 AM, Zoltan Varga var...@gmail.comwrote:
Hi,
On Thu, Jan 6, 2011 at 1:24 AM, Elijah Taylor
elijahtay...@google.com wrote:
Zoltan,
I've rebased from mono's master branch and fixed all merge
conflicts, but something that's gone in since I first forked has now
broken
NaCl AOT compilation for me. On amd64 the compiler just crashes and
I'm
looking into that, nut on x86 I'm getting this: Can't use AOT image
'mscorlib' in aot-only mode because it is not compiled with
--aot=full. But
I'm compiling with --aot=full,static,nodebug,ntrampolines=4096
If need be I can pick through the AOT changes that have gone in, but
I was hoping you or someone on this list would be able to tell me the
major
changes to AOT from the past 3 weeks and some ideas about what might be
getting in my way. Can you shed any light?
There was a big reorganization in the AOT file format to reduce the
number of global symbols exported from the aot images. No idea why this
is
causing problems. make fullaotcheck and make fsacheck still seems to
work
for me on x86. I fixed a uninitilized memory error in 88d676ffd425def3,
maybe that will help.
Zoltan
-Elijah
On Wed, Jan 5, 2011 at 3:51 PM, Zoltan Varga var...@gmail.comwrote:
Hi,
I think the current code looks ok, and we should think about how
to merge it into mono trunk. As a first step, could you rebase your
master
branch on top of master
Re: [Mono-dev] [PATCH] more support for Google Native Client
Also, if any of the memory allocation routines don't get a larger alignment
like pages, and instead just use MIN_ALIGN, yet pass in a larger alignment
requirement to *mono_code_manager_reserve_align*, this code would be needed
too. (sounds a bit contrived I guess :)
On Thu, Jan 6, 2011 at 11:41 AM, Elijah Taylor elijahtay...@google.comwrote:
Page alignment would be good enough, but I wasn't clear because I had
forgotten some details. When I saw this behavior we were using the dummy
implementation of mono_valloc which falls back on malloc, which I don't
believe we use anymore for the AOT compiler since it's a native app.
This code is probably not necessary for NaCl anymore, but if anyone is
using this dummy implementation then it's still a valid fix.
On Thu, Jan 6, 2011 at 11:31 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
Its fixed now, it was missing a (uintptr_t) cast around align_mask.
mono_valloc () is supposed to return pagesize aligned memory, isn't that
enough ?
Zoltan
On Thu, Jan 6, 2011 at 8:14 PM, Elijah Taylor elijahtay...@google.comwrote:
This bit of code runs for our AOT compiler, but not for our JIT (in that
case, it's a native 32-bit app that defines __native_client_codegen__).
The problem is that chunk-data isn't guaranteed to be aligned to
MIN_ALIGN **or** the alignment you pass into *
mono_code_manager_reserve_align* if you use mono_valloc instead of
dlmemalign in *new_codechunk*. But chunk-pos is aligned to the
alignment passed in, so the returned pointer could be misaligned.
As you can see in the alloc function I adjusted it to give MIN_ALIGN - 1
extra bytes to account for this slop, and there's an identical piece to this
below for new codechunks that are allocated. I'm curious why this is
causing problems for non-nacl builds... if chunk-data is aligned this
should essentially be a no-op, and if it's not aligned, this code is
supposed to fix that. Is there a simple test I can run to see the failure?
On Thu, Jan 6, 2011 at 3:43 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
I had to revert this change, as it was causing crashes on amd64:
@@ -357,8 +494,10 @@ mono_code_manager_reserve_align (MonoCodeManager
*cman, int size, int alignment)
for (chunk = cman-current; chunk; chunk = chunk-next) {
if (ALIGN_INT (chunk-pos, alignment) + size = chunk-size) {
chunk-pos = ALIGN_INT (chunk-pos, alignment);
- ptr = chunk-data + chunk-pos;
- chunk-pos += size;
+ /* Align the chunk-data we add to chunk-pos */
+ /* or we can't guarantee proper alignment */
+ ptr = (void*)uintptr_t)chunk-data + align_mask) ~align_mask) +
chunk-pos);
+ chunk-pos = ((char*)ptr - chunk-data) + size;
return ptr;
}
}
it was inside a #ifndef native_client, so why is this needed ?
Zoltan
On Thu, Jan 6, 2011 at 11:34 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
I merged your changes to mono's master except for the following:
runtime/mono-wrapper.in
mono/mini/genmdesc.c
nacl/
Zoltan
On Thu, Jan 6, 2011 at 2:22 AM, Elijah Taylor elijahtay...@google.com
wrote:
Ok, I'll check out the changes/info you mentioned and go through the
files that auto-merged, too. Probably won't get this done for at least a
day or so, but I'll rebase again once I've fixed it. Hopefully by that
point something else won't have broken too :)
-Elijah
On Wed, Jan 5, 2011 at 5:19 PM, Zoltan Varga var...@gmail.comwrote:
Hi,
This should work as follows: every aot image contains a
MonoAotFileInfo structure,
emitted in emit_file_info () in aot-compiler.c, which has a 'flags'
field, and the MONO_AOT_FILE_FLAG_FULL_AOT flag should be set in
this field. At runtime, check_usable() in aot-runtime.c checks this
flag.
Zoltan
On Thu, Jan 6, 2011 at 2:10 AM, Zoltan Varga var...@gmail.comwrote:
Hi,
On Thu, Jan 6, 2011 at 1:24 AM, Elijah Taylor
elijahtay...@google.com wrote:
Zoltan,
I've rebased from mono's master branch and fixed all merge
conflicts, but something that's gone in since I first forked has now
broken
NaCl AOT compilation for me. On amd64 the compiler just crashes and
I'm
looking into that, nut on x86 I'm getting this: Can't use AOT
image 'mscorlib' in aot-only mode because it is not compiled with
--aot=full. But I'm compiling with
--aot=full,static,nodebug,ntrampolines=4096
If need be I can pick through the AOT changes that have gone in,
but I was hoping you or someone on this list would be able to tell me
the
major changes to AOT from the past 3 weeks and some ideas about what
might
be getting in my way. Can you shed any light?
There was a big reorganization in the AOT file format to reduce the
number of global symbols exported from the aot images. No idea why
this is
causing problems. make fullaotcheck and make fsacheck still seems to
work
for me on x86. I fixed a uninitilized memory
Re: [Mono-dev] Git line-ending issues
No, shamefully I thought I could get away with directly editing the file from the GitHub web interface (which actually works fine with files that aren't -crlf). I'll refrain from doing so in the future, as I guess it's not recommended (can't even preview). Do you have an opinion about how I should fix this issue (if there is actually anything to fix)? And aren't all those files defined in the .gitattributes file only there for historical reasons, rather than being something desirable? I wouldn't mind going through files (WinForms only, in my case) to convert them all to the same format, if it's something that sounds any good. - Mail Original - De: Michael Hutchinson m.j.hutchin...@gmail.com À: Stifu st...@free.fr Cc: mono-devel-list@lists.ximian.com Envoyé: Jeudi 6 Janvier 2011 20:35:54 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [Mono-dev] Git line-ending issues On Thu, Jan 6, 2011 at 2:02 PM, Stifu st...@free.fr wrote: Hi guys, I'm having issues with a commit I did (d'oh :(), and would like help to clean up my mess. The commit can be seen here: https://github.com/mono/mono/commit/4d5451a61ce63769083ebad3b1a5d9055a27b6df I only removed a few lines in the file, but the whole file shows up as changed. From what I understand, this is due to a difference in line-ending encoding. Looking at the .gitattributes file in the same folder, I see certain files (including the one I modified) are specified as having a certain line-ending encoding (CRLF). The .gitattributes format is rather unintuitive. crlf means the file is stored as lf in the repo, but converted to/from crlf on windows. -crlf explicitly disables conversions, in case the user has autoconversion enabled for all files. Are you perhaps using a git tools that ignores these attributes? -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Git line-ending issues
On Thu, Jan 6, 2011 at 3:38 PM, st...@free.fr wrote: No, shamefully I thought I could get away with directly editing the file from the GitHub web interface (which actually works fine with files that aren't -crlf). I'll refrain from doing so in the future, as I guess it's not recommended (can't even preview). Do you have an opinion about how I should fix this issue (if there is actually anything to fix)? Don't use tools that autoconvert and ignore .gitattributes. And aren't all those files defined in the .gitattributes file only there for historical reasons, rather than being something desirable? I wouldn't mind going through files (WinForms only, in my case) to convert them all to the same format, if it's something that sounds any good. Conversion without a good reason is bad because it adds a ton of noise to history, for example annotation.becomes ~useless. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] more support for Google Native Client
Hi Zoltan,
I've rebased my fork after your merge and subsequent fixes, and everything
seems to be working great with NaCl (I think the amd64 crash you were seeing
might have been the same one I was seeing). Thanks for the help with
reviewing the code and merging it in, I'm really glad we finally have these
changes upstream.
-Elijah
On Thu, Jan 6, 2011 at 11:50 AM, Elijah Taylor elijahtay...@google.comwrote:
Also, if any of the memory allocation routines don't get a larger alignment
like pages, and instead just use MIN_ALIGN, yet pass in a larger alignment
requirement to *mono_code_manager_reserve_align*, this code would be
needed too. (sounds a bit contrived I guess :)
On Thu, Jan 6, 2011 at 11:41 AM, Elijah Taylor elijahtay...@google.comwrote:
Page alignment would be good enough, but I wasn't clear because I had
forgotten some details. When I saw this behavior we were using the dummy
implementation of mono_valloc which falls back on malloc, which I don't
believe we use anymore for the AOT compiler since it's a native app.
This code is probably not necessary for NaCl anymore, but if anyone is
using this dummy implementation then it's still a valid fix.
On Thu, Jan 6, 2011 at 11:31 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
Its fixed now, it was missing a (uintptr_t) cast around align_mask.
mono_valloc () is supposed to return pagesize aligned memory, isn't that
enough ?
Zoltan
On Thu, Jan 6, 2011 at 8:14 PM, Elijah Taylor
elijahtay...@google.comwrote:
This bit of code runs for our AOT compiler, but not for our JIT (in that
case, it's a native 32-bit app that defines __native_client_codegen__).
The problem is that chunk-data isn't guaranteed to be aligned to
MIN_ALIGN **or** the alignment you pass into *
mono_code_manager_reserve_align* if you use mono_valloc instead of
dlmemalign in *new_codechunk*. But chunk-pos is aligned to the
alignment passed in, so the returned pointer could be misaligned.
As you can see in the alloc function I adjusted it to give MIN_ALIGN - 1
extra bytes to account for this slop, and there's an identical piece to
this
below for new codechunks that are allocated. I'm curious why this is
causing problems for non-nacl builds... if chunk-data is aligned this
should essentially be a no-op, and if it's not aligned, this code is
supposed to fix that. Is there a simple test I can run to see the failure?
On Thu, Jan 6, 2011 at 3:43 AM, Zoltan Varga var...@gmail.com wrote:
Hi,
I had to revert this change, as it was causing crashes on amd64:
@@ -357,8 +494,10 @@ mono_code_manager_reserve_align (MonoCodeManager
*cman, int size, int alignment)
for (chunk = cman-current; chunk; chunk = chunk-next) {
if (ALIGN_INT (chunk-pos, alignment) + size = chunk-size) {
chunk-pos = ALIGN_INT (chunk-pos, alignment);
- ptr = chunk-data + chunk-pos;
- chunk-pos += size;
+ /* Align the chunk-data we add to chunk-pos */
+ /* or we can't guarantee proper alignment */
+ ptr = (void*)uintptr_t)chunk-data + align_mask) ~align_mask)
+ chunk-pos);
+ chunk-pos = ((char*)ptr - chunk-data) + size;
return ptr;
}
}
it was inside a #ifndef native_client, so why is this needed ?
Zoltan
On Thu, Jan 6, 2011 at 11:34 AM, Zoltan Varga var...@gmail.comwrote:
Hi,
I merged your changes to mono's master except for the following:
runtime/mono-wrapper.in
mono/mini/genmdesc.c
nacl/
Zoltan
On Thu, Jan 6, 2011 at 2:22 AM, Elijah Taylor
elijahtay...@google.com wrote:
Ok, I'll check out the changes/info you mentioned and go through the
files that auto-merged, too. Probably won't get this done for at least
a
day or so, but I'll rebase again once I've fixed it. Hopefully by that
point something else won't have broken too :)
-Elijah
On Wed, Jan 5, 2011 at 5:19 PM, Zoltan Varga var...@gmail.comwrote:
Hi,
This should work as follows: every aot image contains a
MonoAotFileInfo structure,
emitted in emit_file_info () in aot-compiler.c, which has a 'flags'
field, and the MONO_AOT_FILE_FLAG_FULL_AOT flag should be set in
this field. At runtime, check_usable() in aot-runtime.c checks this
flag.
Zoltan
On Thu, Jan 6, 2011 at 2:10 AM, Zoltan Varga var...@gmail.comwrote:
Hi,
On Thu, Jan 6, 2011 at 1:24 AM, Elijah Taylor
elijahtay...@google.com wrote:
Zoltan,
I've rebased from mono's master branch and fixed all merge
conflicts, but something that's gone in since I first forked has now
broken
NaCl AOT compilation for me. On amd64 the compiler just crashes and
I'm
looking into that, nut on x86 I'm getting this: Can't use AOT
image 'mscorlib' in aot-only mode because it is not compiled with
--aot=full. But I'm compiling with
--aot=full,static,nodebug,ntrampolines=4096
If need be I can pick through the AOT changes that have gone in,
but I was hoping you or someone on this list
Re: [Mono-dev] File not found error when using Activator.CreateInstanceFrom()
Thanks for the reply. Not sure what you mean as I'm not doing a LoadLibrary(). Compile the sample code(s) above in this post for an example of how to produce the error. Note that the sample runs fine under the .NET 2.0 CLR on Windows and fails under mono 2.9 under Windows. I tried setting the LD_LIBRARY_PATH as you suggested anyway and that did not work. -- View this message in context: http://mono.1490590.n4.nabble.com/File-not-found-error-when-using-Activator-CreateInstanceFrom-tp3064104p3178277.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
