[Mono-dev] Building mono-debugger 0.60 problem
Hi, I'm trying to build mono-debugger 0.60 on my F9 box (running on rawhide, but that's not really anything new and everything normally just builds). Besides a small patch needed to build the server on the backend (attached) I seem to be hitting a problem just building it. Is there a fix in the pipeline? I'm using the tarball from the mono website to build. I'm building on an x86_64 box against mono-1.9.1 TTFN Paul (throwback from build below - lots of warnings, errors at the end) + make hashtab.c: In function 'find_empty_slot_for_expand': hashtab.c:331: warning: declaration of 'index' shadows a global declaration /usr/include/string.h:309: warning: shadowed declaration is here hashtab.c: In function 'htab_find_with_hash': hashtab.c:430: warning: declaration of 'index' shadows a global declaration /usr/include/string.h:309: warning: shadowed declaration is here hashtab.c: In function 'htab_find_slot_with_hash': hashtab.c:487: warning: declaration of 'index' shadows a global declaration /usr/include/string.h:309: warning: shadowed declaration is here elf64-x86-64.c:37: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:40: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:43: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:46: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:49: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:52: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:55: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:58: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:61: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:64: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:67: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:70: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:73: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:75: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:77: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:79: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:81: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:84: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:87: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:90: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:93: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:96: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:99: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:102: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:107: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c:111: warning: initialization discards qualifiers from pointer target type elf64-x86-64.c: In function 'elf64_x86_64_grok_prstatus': elf64-x86-64.c:270: warning: pointer targets in passing argument 1 of 'abfd-xvec-bfd_getx16' differ in signedness elf64-x86-64.c:274: warning: pointer targets in passing argument 1 of 'abfd-xvec-bfd_getx32' differ in signedness elf64-x86-64.c:285: warning: passing argument 2 of '_bfd_elfcore_make_pseudosection' discards qualifiers from pointer target type elf64-x86-64.c: In function 'elf64_x86_64_size_dynamic_sections': elf64-x86-64.c:1640: warning: dereferencing type-punned pointer will break strict-aliasing rules In file included from elf64-x86-64.c:2948: elf64-target.h: At top level: elf64-target.h:624: warning: initialization discards qualifiers from pointer target type In file included from elfcode.h:1577, from elf64.c:23: elflink.h: In function 'bfd_elf64_bfd_final_link': elflink.h:5539: warning: declaration of 'o' shadows a previous local elflink.h:5086: warning: shadowed declaration is here elf32-i386.c:95: warning: initialization discards qualifiers from pointer target type elf32-i386.c:98: warning: initialization discards qualifiers from pointer target type elf32-i386.c:101: warning: initialization discards qualifiers from pointer target type elf32-i386.c:104: warning: initialization discards qualifiers from pointer target type elf32-i386.c:107: warning: initialization discards qualifiers from pointer target type elf32-i386.c:110: warning: initialization discards qualifiers from pointer target type elf32-i386.c:113: warning: initialization discards qualifiers from pointer target type elf32-i386.c:116: warning:
Re: [Mono-dev] crashes in glib hangs (not exits) program
doing nothing. Hope I am clear this time. Looking at the stack trace I _think_ its just some bug in mono's after-crash-stacktrace-printer which is causing the problem. Mono's behaviour (and yours too) is absolutely right otherwise. It's most likely the g_spawn* that gets the stack trace from gdb. You may try to comment out the offending code in mini/mini-exceptions.c. Little progress: I mentioned this on the bug page but I will do it here too. Setting the SIGABRT handler to SIG_DFL seems to work. I noticed that after the crash - mono starts gdb to get information about the threads et al - abort() - this somehow brought the control back to mono, which it shouldnt - the stacktrace read like (mono) (libc) (libc) (gsignal) (abort) ... This could be a red-herring but it prompted me to try after removing mono's sigabrt handler. Overriding mono's sigabrt handler by the default one does not print the nice mono stacktrace but crashes exactly the way it would do on a native segfault. Overriding SIGABRT seems like a working workaround. Some kind of flag/option to control this behaviour would be nice though. What would be best is to get both the mono stacktrace and successfully abort after that :-). - dBera -- - Debajyoti Bera @ http://dtecht.blogspot.com beagle / KDE fan Mandriva / Inspiron-1100 user ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] IOKit Enumeration
Dick, do you have any input on this before I start implementing the Win32 Comm API in io-layer? On Apr 21, 2008, at 5:53 AM, Geoff Norton wrote: Josh, At a high level it does, but this conversation should be moved over to mono-devel-list, so that the approrpiate maintainers (Dick Porter) can weigh in. I've cc'd Dick and the mono-devel-list, dropping mono-osx. -g On 21-Apr-08, at 2:32 AM, Joshua Perry wrote: It seems that I misunderstood what io-layer is. From what I gather, it is a Win32 compatibility layer that steps in with Win32 API IO functions on non Windows builds of mono. It looks like io-layer already implements File IO functions and overlapped IO operations. If I implement the Comm specific functions in io-layer we should be able to unify the System.IO.Ports code to the WinSerialStream code. Though changing it from P/Invoking into kernel32.dll to using icalls to io-layer. Win32 Comm API Functions: SetupComm PurgeComm SetCommTimeouts GetCommState SetCommState ClearCommError GetCommModemStatus EscapeCommFunction Does this sound right to you? Josh On Apr 19, 2008, at 8:06 AM, Geoff Norton wrote: Josh, On 15-Apr-08, at 10:49 AM, Joshua Perry wrote: The current SerialPort chooses between two ISerialStream implementations SerialPortStream and WinSerialStream. SerialPortStream is implemented by P/Invoking into MonoPosixHelper functions like serial_read and serial_write. WinSerialStream is implemented by P/Invoking the Win32 API serial port and IO functions. Outside of enumerating IOKit objects to find the port /dev/ nodes, I believe that OSX is compatible with standard posix callsl though I'm not happy with the current Posix stream as Async operations are not implemented. I would like to implement the async functionality and, from the look of things, moving the serial specific functions into io- layer would be the right thing to do. Great, let us know if there are any questions / problems. In XplatUI.cs are you talking about the call to uname to check for Darwin? Yep -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling Mono from Source Code
Paramesh, The following link is what I use. I have found it extremely useful. http://shana.iidbbs.com/en/mono_cygwin_tutorial.html ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows
Hi,
Now I redesigned several things but still fails to compile:
/mono/mono/mono/metadata/domain.c:1216: undefined reference to
[EMAIL PROTECTED]'
/mono/mono/mono/metadata/domain.c:1171: undefined reference to
[EMAIL PROTECTED]'
If I add this to domain.c it compiles just fine:
#include mono/metadata/coree.c
I really have no idea what sould I modify. Please help.
And also please review the patch and if you like it please approve it.
Kornél
- Original Message -
From: Kornél Pál [EMAIL PROTECTED]
To: mono-devel-list@lists.ximian.com; Robert Jordan [EMAIL PROTECTED]
Sent: Monday, April 21, 2008 11:59 PM
Subject: Re: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows
Hi,
Thank you very much for pointing out this difference. Note that if it's
really necessary I prefer to create a mono_runtime_init or similar
callback supplied by mini over splitting the code because MonoFixupCorEE
requires the address of the other functions and is used by metadata so it
would be difficult to split the file.
But unfortunately I still get the same errors even after commenting out
references to mini headers and functions:
/mono/mono/mono/metadata/domain.c:1172: undefined reference to
[EMAIL PROTECTED]'
/mono/mono/mono/metadata/domain.c:1217: undefined reference to
[EMAIL PROTECTED]'
Kornél
- Original Message -
From: Robert Jordan [EMAIL PROTECTED]
To: mono-devel-list@lists.ximian.com
Sent: Sunday, April 20, 2008 9:43 PM
Subject: Re: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows
Hi Kornél,
Kornél Pál wrote:
Now I consider the patch being complete for inclusion in Mono. But I
still didn't manage to build it using cygwin so I need some help.
mini functions cannot be called from metadata/coree.c.
The VC build does not care because it's one huge compilation unit,
but the automake build consists of several compilation units (libs).
You should split coree.c in 2 parts: the _Cor*/Cor* functions
inside the mini tree and the rest in metadata.
This will fix the cygwin build.
Robert
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Index: mono/libgc/win32_threads.c
===
--- mono/libgc/win32_threads.c (revision 101236)
+++ mono/libgc/win32_threads.c (working copy)
@@ -782,7 +782,7 @@
* Pontus Rydin suggests wrapping the thread start routine instead.
*/
#if defined(GC_DLL) || defined(GC_INSIDE_DLL)
-BOOL WINAPI DllMain(HINSTANCE inst, ULONG reason, LPVOID reserved)
+BOOL WINAPI GC_DllMain(HINSTANCE inst, ULONG reason, LPVOID reserved)
{
switch (reason) {
case DLL_PROCESS_ATTACH:
Index: mono/libgc/include/gc.h
===
--- mono/libgc/include/gc.h (revision 101236)
+++ mono/libgc/include/gc.h (working copy)
@@ -922,6 +922,8 @@
#if defined(GC_WIN32_THREADS) !defined(__CYGWIN32__) !defined(__CYGWIN__)
# include windows.h
+ BOOL WINAPI GC_DllMain(HINSTANCE inst, ULONG reason, LPVOID reserved);
+
/*
* All threads must be created using GC_CreateThread, so that they will be
* recorded in the thread table. For backwards compatibility, this is not
Index: mono/mono/metadata/loader.c
===
--- mono/mono/metadata/loader.c (revision 101236)
+++ mono/mono/metadata/loader.c (working copy)
@@ -1394,12 +1394,20 @@
if (cols [1] METHOD_IMPL_ATTRIBUTE_INTERNAL_CALL) {
if (result-klass == mono_defaults.string_class !strcmp (result-name,
.ctor))
result-string_ctor = 1;
- } else if ((cols [2] METHOD_ATTRIBUTE_PINVOKE_IMPL) (!(cols [1]
METHOD_IMPL_ATTRIBUTE_NATIVE))) {
+ } else if (cols [2] METHOD_ATTRIBUTE_PINVOKE_IMPL) {
MonoMethodPInvoke *piinfo = (MonoMethodPInvoke *)result;
- MonoTableInfo *im = tables [MONO_TABLE_IMPLMAP];
+#ifdef PLATFORM_WIN32
+ /* IJW is P/Invoke with a predefined function pointer */
+ if (image-is_module_handle (cols [1]
METHOD_IMPL_ATTRIBUTE_NATIVE)) {
+ piinfo-addr = mono_image_rva_map (image, cols [0]);
+ g_assert (piinfo-addr);
+ }
+#endif
piinfo-implmap_idx = mono_metadata_implmap_from_method (image,
idx - 1);
- piinfo-piflags = mono_metadata_decode_row_col (im,
piinfo-implmap_idx - 1, MONO_IMPLMAP_FLAGS);
+ /* native methods can have no map */
+ if (piinfo-implmap_idx)
+ piinfo-piflags = mono_metadata_decode_row_col (tables
[MONO_TABLE_IMPLMAP], piinfo-implmap_idx - 1, MONO_IMPLMAP_FLAGS);
}
/* FIXME: lazyness for generics too, but how? */
@@ -1900,7 +1908,7 @@
if (m-iflags METHOD_IMPL_ATTRIBUTE_INTERNAL_CALL)
Re: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows
Hi Kornél,
Kornél Pál wrote:
Now I redesigned several things but still fails to compile:
/mono/mono/mono/metadata/domain.c:1216: undefined reference to
[EMAIL PROTECTED]'
/mono/mono/mono/metadata/domain.c:1171: undefined reference to
[EMAIL PROTECTED]'
If I add this to domain.c it compiles just fine:
#include mono/metadata/coree.c
I really have no idea what sould I modify. Please help.
And also please review the patch and if you like it please approve it.
I think the following code is from another patch set (the cmd line
encoding issue you sent a patch for). Is it complete?
If this is solved, I will try to fix the cygwin build.
Robert
Index: mono/mono/mini/main.c
===
--- mono/mono/mini/main.c(revision 101236)
+++ mono/mono/mini/main.c(working copy)
@@ -1,8 +1,31 @@
#include mini.h
+#ifdef PLATFORM_WIN32
+
int
+main ()
+{
+int argc;
+gunichar2** argvw;
+gchar** argv;
+int i;
+
+argvw = CommandLineToArgvW (GetCommandLine (), argc);
+argv = g_new0 (char*, argc);
+for (i = 0; i argc; i++)
+argv [i] = g_utf16_to_utf8 (argvw [i], -1, NULL, NULL, NULL);
+
+LocalFree (argvw);
+
+return mono_main (argc, argv);
+}
+
+#else
+
+int
main (int argc, char* argv[])
{
return mono_main (argc, argv);
}
+#endif
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] SIGILL in finally clause without catch
In code I have to port from MS .NET to mono I observed several SIGILL
crashes at points in code, where calls to external code are made
within a try block followed by a finally but *without* a catch
statement.
try {
unrar.dosomething();
throw new Exception(test);
}
// no catch here
finally
{
unrar.close(); // calls unmanaged code
}
The unmanaged code called in unrar.dosomething() is C++ code compiled
with exceptions enabled but it does not throw the exception, but the
managed code that follows. The call to unrar.close() (which does not
throw any exception) in the finally clause crashes with:
System.ExecutionEngineException: SIGILL
at (wrapper managed-to-native)
NntpApp.nntp.rar.Unrar:RARCloseArchive (intptr)
at NntpApp.nntp.rar.Unrar.Close () [0x0]
at usenextapp.FilegroupPreview.ExtractFileFromRar (System.String
path) [0x0]
The SIGILL does not appear if I catch the exception and rethrow it in
the finally clause
Exception e=null;
try {
unmanaged1();
throw new Exception(test);
}
catch(Exception ex)
{
e= ex;
}
finally
{
cleanup();
if (e!=null)
throw e;
}
Any thoughts on that?
Christian Stümpel
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
