From: Thomas P. <tp...@gm...> - 2002-11-08 10:28:47
|
Hi Danny, i just had the time to look at the eh changes in gcc-3 for throwing exceptions across DLL/EXE boundaries. While the code works in 99% for cygwin and mingw it has one disadvantage for cygwin: The atom name is lost after a fork. See following example: #include <stdio.h> #include <unistd.h> #include <sys/wait.h> #include <pthread.h> #include <iostream> using namespace std; #define WIN32_LEAN_AND_MEAN #include <windows.h> #define SHAREDPTR_LETTER0 'a' #define SHAREDPTR_LETTER1 'A' int main (void) { char s[sizeof(void*) * 8 + 1]; ATOM atom; try { memset (s, SHAREDPTR_LETTER0, sizeof(void*) * 8); s[sizeof(void*) * 8] = '\0'; switch (fork ()) { case -1: return 0; case 0: atom = FindAtomA (s); throw "child"; default: atom = FindAtomA (s); throw "parent"; } } catch (const char *str) { char szAtom[16]; sprintf( szAtom, "0x%08x", (int) atom ); cout << "got " << str << "s exception, atom " << szAtom << endl; } catch (...) { cout << "got exception" << endl; } return 0; } If a dll is loaded dynamically after a fork the shared information is lost and throwing exceptions from a dll does not work anymore. For that reason i have created a different version that uses a shared pointer that is contained in the cygwin1.dll, now it works in all test cases. (And since i always link against libmingwthrd.a i added this function to mthr.c too, but this is not applicable for all mingw users). I have attached my code. You may notice that i have moved 2 additional static vars in the shared area (object_mutex and marker from unwind-dw2-fde.c) and that i have modified the shared pointer allocation a bit. Comments are welcome. Thomas |
From: Christopher F. <cg...@re...> - 2002-11-08 16:29:32
|
On Fri, Nov 08, 2002 at 11:28:26AM +0100, Thomas Pfaff wrote: > >Hi Danny, > >i just had the time to look at the eh changes in gcc-3 for throwing >exceptions across DLL/EXE boundaries. >While the code works in 99% for cygwin and mingw it has one disadvantage >for cygwin: The atom name is lost after a fork. Why? cgf |
From: <ch...@it...> - 2002-11-09 02:12:05
|
Hi. I'm preparing the gcc fastcall patch for submission. I'm unable to find a changelog entry for the change below. Danny, is this yours? If this change is needed for fastcall support, I would appreciate a changelog entry for it. Thanks, Casper @@ -658,6 +706,15 @@ i386_pe_record_exported_symbol (name, is export_head = p; } +/* Return non-zero if SYMBOL is marked as being fascall. */ + +static int +i386_pe_fastcall_name_p (symbol) + const char *symbol; +{ + return symbol[0] == '+' || (symbol[0] == '@' && symbol[3] == '+'); +} + /* This is called at the end of assembly. For each external function which has not been defined, we output a declaration now. We also output the .drectve section. */ @@ -690,7 +747,8 @@ i386_pe_asm_file_end (file) drectve_section (); for (q = export_head; q != NULL; q = q->next) { - fprintf (file, "\t.ascii \" -export:%s%s\"\n", + fprintf (file, "\t.ascii \" -export:%s%s%s\"\n", + (i386_pe_fastcall_name_p(q->name)) ? "@" : "", i386_pe_strip_name_encoding (q->name), (q->is_data) ? ",data" : ""); } |
From: Danny S. <dan...@cl...> - 2002-11-09 07:21:36
|
----- Original Message ----- From: <ch...@it...> To: <min...@li...> Sent: Friday, 8 November 2002 17:49 Subject: [MinGW-dvlpr] Missing changelog entry for gcc fastcall patch > Hi. > > I'm preparing the gcc fastcall patch for submission. > I'm unable to find a changelog entry for the change below. > > Danny, is this yours? If this change is needed for fastcall > support, I would appreciate a changelog entry for it. > Eric's It is needed. Danny > Thanks, > Casper > > > @@ -658,6 +706,15 @@ i386_pe_record_exported_symbol (name, is > export_head = p; > } > > +/* Return non-zero if SYMBOL is marked as being fascall. */ > + > +static int > +i386_pe_fastcall_name_p (symbol) > + const char *symbol; > +{ > + return symbol[0] == '+' || (symbol[0] == '@' && symbol[3] == '+'); > +} > + > /* This is called at the end of assembly. For each external function > which has not been defined, we output a declaration now. We also > output the .drectve section. */ > @@ -690,7 +747,8 @@ i386_pe_asm_file_end (file) > drectve_section (); > for (q = export_head; q != NULL; q = q->next) > { > - fprintf (file, "\t.ascii \" -export:%s%s\"\n", > + fprintf (file, "\t.ascii \" -export:%s%s%s\"\n", > + (i386_pe_fastcall_name_p(q->name)) ? "@" : "", > i386_pe_strip_name_encoding (q->name), > (q->is_data) ? ",data" : ""); > } > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: <ch...@it...> - 2002-11-09 05:00:05
|
"__imp__" is added in ASM_OUTPUT_LABELREF, but "_imp__" is removed in i386_pe_mark_dllimport. Is this a fastcall change or an unrelated change that should be in a separate patch? @@ -271,9 +273,25 @@ do { \ /* Output a reference to a label. */ #undef ASM_OUTPUT_LABELREF -#define ASM_OUTPUT_LABELREF(STREAM, NAME) \ - fprintf (STREAM, "%s%s", USER_LABEL_PREFIX, \ - i386_pe_strip_name_encoding (NAME)) \ +#define ASM_OUTPUT_LABELREF(STREAM, NAME) \ +do { \ + if (strncmp (NAME,"@i.",3) == 0) \ + { \ + if (NAME[3] == '+') \ + fprintf (STREAM, "__imp_@%s", \ + i386_pe_strip_name_encoding (NAME)); \ + else \ + fprintf (STREAM, "__imp__%s", \ + i386_pe_strip_name_encoding (NAME)); \ + } \ + else if ((NAME[0] == '+') || \ + ((NAME[0] == '@') && (NAME[3] == '+'))) \ + fprintf (STREAM, "@%s", \ + i386_pe_strip_name_encoding (NAME)); \ + else \ + fprintf (STREAM, "%s%s", user_label_prefix, \ + i386_pe_strip_name_encoding (NAME)); \ +} while (0) @@ -311,8 +313,8 @@ i386_pe_mark_dllimport (decl) return; } - newname = alloca (strlen (oldname) + 11); - sprintf (newname, "@i._imp__%s", oldname); + newname = alloca (strlen (oldname) + 4); + sprintf (newname, "@i.%s", oldname); /* We pass newname through get_identifier to ensure it has a unique address. RTL processing can sometimes peek inside the symbol ref |
From: Danny S. <dan...@cl...> - 2002-11-09 07:19:38
|
Umm, ASM_OUTPUT_LABELREF adds the user label prefix (the first underscore). i386_pe_mark_dllimport doesn't, because ASM_OUTPUT_LABEL_REF will No change in behaviour from pre-fastcall, just an adjustment because of the '@' that replaces user_label_prefix. Where l is Eric, we've been through all this before. Danny ----- Original Message ----- From: <ch...@it...> To: <min...@li...> Sent: Friday, 8 November 2002 18:18 Subject: [MinGW-dvlpr] Fastcall or other change ? > "__imp__" is added in ASM_OUTPUT_LABELREF, but "_imp__" > is removed in i386_pe_mark_dllimport. > > Is this a fastcall change or an unrelated change that should > be in a separate patch? > > > @@ -271,9 +273,25 @@ do { > \ > > > /* Output a reference to a label. */ > #undef ASM_OUTPUT_LABELREF > -#define ASM_OUTPUT_LABELREF(STREAM, NAME) \ > - fprintf (STREAM, "%s%s", USER_LABEL_PREFIX, \ > - i386_pe_strip_name_encoding (NAME)) \ > +#define ASM_OUTPUT_LABELREF(STREAM, NAME) \ > +do { \ > + if (strncmp (NAME,"@i.",3) == 0) \ > + { \ > + if (NAME[3] == '+') \ > + fprintf (STREAM, "__imp_@%s", \ > + i386_pe_strip_name_encoding (NAME)); \ > + else \ > + fprintf (STREAM, "__imp__%s", \ > + i386_pe_strip_name_encoding (NAME)); \ > + } \ > + else if ((NAME[0] == '+') || \ > + ((NAME[0] == '@') && (NAME[3] == '+'))) \ > + fprintf (STREAM, "@%s", \ > + i386_pe_strip_name_encoding (NAME)); \ > + else \ > + fprintf (STREAM, "%s%s", user_label_prefix, \ > + i386_pe_strip_name_encoding (NAME)); \ > +} while (0) > > > > @@ -311,8 +313,8 @@ i386_pe_mark_dllimport (decl) > return; > } > > - newname = alloca (strlen (oldname) + 11); > - sprintf (newname, "@i._imp__%s", oldname); > + newname = alloca (strlen (oldname) + 4); > + sprintf (newname, "@i.%s", oldname); > > /* We pass newname through get_identifier to ensure it has a unique > address. RTL processing can sometimes peek inside the symbol ref > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Thomas P. <tp...@gm...> - 2002-11-11 13:13:20
|
On Fri, 8 Nov 2002, Christopher Faylor wrote: > On Fri, Nov 08, 2002 at 11:28:26AM +0100, Thomas Pfaff wrote: > > > >Hi Danny, > > > >i just had the time to look at the eh changes in gcc-3 for throwing > >exceptions across DLL/EXE boundaries. > >While the code works in 99% for cygwin and mingw it has one disadvantage > >for cygwin: The atom name is lost after a fork. > > Why? Because it is allocated via AddAtom and is local to the process. After a fork the name is lost. BTW: In unwind-dw2-fde.c a mutex is used to synchronize access to a linked list. In the current code this mutex is not shared and therefore it does not synchronize access between code in DLLs and the executable. I would recommend to make this mutex shared too (see my unwind-dw2-fde.c patch and w32-shared-ptr.c). Thomas |
From: Danny S. <dan...@cl...> - 2002-11-11 20:21:40
|
> BTW: In unwind-dw2-fde.c a mutex is used to synchronize access to a linked > list. In the current code this mutex is not shared and therefore it does > not synchronize access between code in DLLs and the executable. > I would recommend to make this mutex shared too (see my unwind-dw2-fde.c > patch and w32-shared-ptr.c). > > Thomas > I agree with the shared pointer to mutex. I want to make the whole shared pointer business work for sjlj as well as dwarf2. With sjlj the pointers have to be initialised before main(), since main itself can throw exceptions and it needs the pointers in the prologue. So that means a dependency on crt startup objects. In mingw we can just call the initialisation code before main within __mingw_CRTStartup in crt1.c and in dllcrt1.c in DllMainCRTStartup, case dwReason == DLL_PROCESS_ATTACH. I haven't looked at cygwin startup code, but something similar there. The main problem with all this is for users with old mingw/cygwin runtime and new gcc. So we need to have fallback static initialisation of the globals, in an extern object in libgcc.a. If the shared_ptr initialisation call is made by the runtime, this object won't get linked in. If the initialisation call is _not_ there, the pointers aren't shared, but at least they get allocated. So, I'll work on incorporating your patches into that framework. Danny > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Danny S. <dan...@cl...> - 2002-11-12 23:30:10
|
----- Original Message ----- From: "Thomas Pfaff" <tp...@gm...> To: <cyg...@cy...> Cc: <min...@li...> Sent: Monday, 11 November 2002 13:13 Subject: [MinGW-dvlpr] Re: Exception handling in gcc-3 > > > BTW: In unwind-dw2-fde.c a mutex is used to synchronize access to a linked > list. In the current code this mutex is not shared and therefore it does > not synchronize access between code in DLLs and the executable. > I would recommend to make this mutex shared too (see my unwind-dw2-fde.c > patch and w32-shared-ptr.c). > > Thomas Unless I'm missing something, sjlj wouldn't need these extra shared mutex ptrs. Danny > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Thomas P. <tp...@gm...> - 2002-11-13 07:59:51
|
On Tue, 12 Nov 2002, Danny Smith wrote: > > ----- Original Message ----- > From: "Thomas Pfaff" <tp...@gm...> > To: <cyg...@cy...> > Cc: <min...@li...> > Sent: Monday, 11 November 2002 13:13 > Subject: [MinGW-dvlpr] Re: Exception handling in gcc-3 > > > > > > > > BTW: In unwind-dw2-fde.c a mutex is used to synchronize access to a > linked > > list. In the current code this mutex is not shared and therefore it > does > > not synchronize access between code in DLLs and the executable. > > I would recommend to make this mutex shared too (see my > unwind-dw2-fde.c > > patch and w32-shared-ptr.c). > > > > Thomas > > Unless I'm missing something, sjlj wouldn't need these extra shared > mutex ptrs. > Danny I just had a look at unwind-sjl.c, i would suggest static struct SjLj_Function_Context *fc_static; static __gthread_key_t fc_key; static int use_fc_key = -1; and once in fc_key_init_once to be in shared memory. Actually i am looking at the dwarf2 problems with stdcall functions. AFAICT the context in _Unwind_RaiseException contains an invalid return address (ra) after some stack unwindings and a handler for the exception is not found. I am investigating a bit further why the unwind information is setup incorrect, but: IMHO it does not make sense to stay with dwarf2 if JAVA requires SJLJ exceptions. The information about this is a bit contradictory. Thomas |
From: Danny S. <dan...@cl...> - 2002-11-13 09:01:16
|
----- Original Message ----- From: "Thomas Pfaff" <tp...@gm...> To: "Danny Smith" <dan...@us...> Cc: <min...@li...> Sent: Wednesday, 13 November 2002 07:59 Subject: Re: Re [2]: [MinGW-dvlpr] Re: Exception handling in gcc-3 > > > > Thomas > > > > Unless I'm missing something, sjlj wouldn't need these extra shared > > mutex ptrs. > > Danny > > I just had a look at unwind-sjl.c, i would suggest > > static struct SjLj_Function_Context *fc_static; Yes, I had already put that in for exceptions (single-thread). Thats the one that has to be initialised before main. > static __gthread_key_t fc_key; > static int use_fc_key = -1; > > and once in fc_key_init_once to be in shared memory. > Thanks I had thought that mingw10m.dll took care of the thread key stuff when -mthreads, but I see that I need to revisit. > Actually i am looking at the dwarf2 problems with stdcall functions. > AFAICT the context in _Unwind_RaiseException contains an invalid return > address (ra) after some stack unwindings and a handler for the exception > is not found. > > I am investigating a bit further why the unwind information is setup > incorrect, but: IMHO it does not make sense to stay with dwarf2 if JAVA > requires SJLJ exceptions. I don't think it requires SJLJ in an absolute sense. However, for dwarf2 to work with Java, support is needed in crtstuff.c or somewhere in startup code. Danny The information about this is a bit > contradictory. > > Thomas > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Are you worried about > your web server security? Click here for a FREE Thawte > Apache SSL Guide and answer your Apache SSL security > needs: http://www.gothawte.com/rd523.html > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Danny S. <dan...@cl...> - 2002-11-20 00:30:35
Attachments:
gcc-3_3-2002-11-19.diff.gz
runtime.diff.gz
|
> I just had a look at unwind-sjl.c, i would suggest > > static struct SjLj_Function_Context *fc_static; > static __gthread_key_t fc_key; > static int use_fc_key = -1; > > and once in fc_key_init_once to be in shared memory. > I've add the sjlj gthread variables to the shared pointer machinery using your organization of the pointers into a structure. For now, I initilialise both Dwarf2 and SJLJ ptrs so that I can use the same startup code for both Dwarf2 and sjlj GCC builds.. If wanted, the ones we don't use could be ifdef out with builtin define ___USING_SJLJ_EXCEPTIONS. Note that these pointers have to be initialized before main, since main can throw exceptions and it needs the eh objects in its prologue. Hence, explicit call of __w32_sharedptr_initialize in startup code rather than using constructor mechnism. I have split things up so that new GCC builds can work with old mingw/cygwin runtime. The global pointers get defined in extern file so that even if runtime does not call __w32_sharedptr_initialize they are still allocated. I have also added a dummy __w32_sharedptr_initialize to libmingwex.a for mingw, to avoid undefined reference when using the new mingw runtime with gcc-2.95. An alterrnative would be add the dummy to 2.95's libgcc.a I haven't done much testing at all with threads and exceptions, but at least it still works okay in single-thread tests, both SJLJ and DW2 (modulo the stack corruption problem with -fomit-frame-pointer/__stdcall/-mno-accumulate-outgoing-args and DW2). If testing DW2, be sure -march < i686, since i686 turns on -maccumulate-outgoing-args. I haven't looked at how to incorporate in Cygwin dll. Nor have I used the *__get_w32_eh_sharedptr() approach for mingw. Attached are diffs against GCC3.3 (C and C++ only) and against mingw-runtime. The GCC diffs have a lot of other modifications as well. Tell me if you have problems pulling out the EH specific stuff from the rest. Danny |
From: Jerry v. D. <jv...@at...> - 2002-11-20 03:02:46
|
Danny Smith writes: > Attached are diffs against GCC3.3 (C and C++ only) and against > mingw-runtime. The GCC diffs have a lot of other modifications as well. > Tell me if you have problems pulling out the EH specific stuff from the > rest. mingw patch went OK, but gcc gave problems, see log below. Do I have to apply this patch to a clean checkout of gcc ? patching file gcc/gcc/config.gcc Hunk #1 FAILED at 1269. Hunk #2 FAILED at 1301. 2 out of 2 hunks FAILED -- saving rejects to file gcc/gcc/config.gcc.rej patching file gcc/gcc/crtstuff.c Hunk #1 succeeded at 209 with fuzz 2 (offset 83 lines). Hunk #2 FAILED at 625. 1 out of 2 hunks FAILED -- saving rejects to file gcc/gcc/crtstuff.c.rej patching file gcc/gcc/gcc.c Hunk #1 succeeded at 3009 with fuzz 2 (offset 278 lines). Hunk #2 FAILED at 3067. Hunk #3 FAILED at 3081. Hunk #4 succeeded at 4452 (offset -225 lines). Hunk #5 succeeded at 4986 (offset 278 lines). 2 out of 5 hunks FAILED -- saving rejects to file gcc/gcc/gcc.c.rej patching file gcc/gcc/libgcc2.c patching file gcc/gcc/unwind-dw2-fde.c Hunk #1 FAILED at 43. Hunk #2 succeeded at 84 (offset 8 lines). Hunk #4 succeeded at 498 (offset 8 lines). 1 out of 4 hunks FAILED -- saving rejects to file gcc/gcc/unwind-dw2-fde.c.rej patching file gcc/gcc/unwind-sjlj.c patching file gcc/gcc/config/i386/cygwin.h Hunk #1 FAILED at 20. Hunk #2 FAILED at 31. Hunk #3 succeeded at 71 (offset 14 lines). Hunk #5 succeeded at 102 (offset 14 lines). Hunk #6 FAILED at 111. 3 out of 6 hunks FAILED -- saving rejects to file gcc/gcc/config/i386/cygwin.h.rej patching file gcc/gcc/config/i386/gthr-win32.c patching file gcc/gcc/config/i386/i386.c Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 9 out of 9 hunks ignored -- saving rejects to file gcc/gcc/config/i386/i386.c.rej patching file gcc/gcc/config/i386/i386.h Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file gcc/gcc/config/i386/i386.h.rej patching file gcc/gcc/config/i386/mingw32.h Hunk #2 FAILED at 30. Hunk #3 FAILED at 58. Hunk #4 FAILED at 98. 3 out of 4 hunks FAILED -- saving rejects to file gcc/gcc/config/i386/mingw32.h.rej patching file gcc/gcc/config/i386/t-cygwin patching file gcc/gcc/config/i386/t-mingw32 Hunk #1 FAILED at 4. 1 out of 1 hunk FAILED -- saving rejects to file gcc/gcc/config/i386/t-mingw32.rej patching file gcc/gcc/config/i386/winnt.c Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 19 out of 19 hunks ignored -- saving rejects to file gcc/gcc/config/i386/winnt.c.rej patching file gcc/gcc/config/i386/xm-mingw32.h Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 2 out of 2 hunks ignored -- saving rejects to file gcc/gcc/config/i386/xm-mingw32.h.rej patching file gcc/gcc/doc/extend.texi Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file gcc/gcc/doc/extend.texi.rej patching file gcc/gcc/doc/invoke.texi Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 2 out of 2 hunks ignored -- saving rejects to file gcc/gcc/doc/invoke.texi.rej patching file gcc/libstdc++-v3/config/io/basic_file_stdio.cc patching file gcc/libstdc++-v3/config/os/mingw32/os_defines.h Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file gcc/libstdc++-v3/config/os/mingw32/os_defines.h.rej patching file gcc/libstdc++-v3/include/bits/locale_facets.tcc Hunk #1 succeeded at 560 (offset -13 lines). Hunk #2 FAILED at 913. Hunk #3 FAILED at 946. Hunk #4 succeeded at 630 with fuzz 1 (offset -370 lines). Hunk #5 succeeded at 1183 with fuzz 1 (offset -15 lines). Hunk #6 succeeded at 1285 with fuzz 2 (offset 16 lines). 2 out of 6 hunks FAILED -- saving rejects to file gcc/libstdc++-v3/include/bits/locale_facets.tcc.rej patching file gcc/libstdc++-v3/libsupc++/eh_alloc.cc patching file gcc/libstdc++-v3/libsupc++/eh_globals.cc patching file gcc/libstdc++-v3/libsupc++/eh_terminate.cc Hunk #1 FAILED at 36. Hunk #2 succeeded at 58 (offset 2 lines). 1 out of 3 hunks FAILED -- saving rejects to file gcc/libstdc++-v3/libsupc++/eh_terminate.cc.rej patching file gcc/libstdc++-v3/libsupc++/typeinfo Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file gcc/libstdc++-v3/libsupc++/typeinfo.rej patching file gcc/libstdc++-v3/libsupc++/unwind-cxx.h Hunk #1 FAILED at 125. 1 out of 1 hunk FAILED -- saving rejects to file gcc/libstdc++-v3/libsupc++/unwind-cxx.h.rej patching file gcc/libstdc++-v3/src/globals.cc patching file gcc/libstdc++-v3/src/locale.cc Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file gcc/libstdc++-v3/src/locale.cc.rej patching file gcc/gcc/config/i386/cygming.h patching file gcc/gcc/config/i386/cygwin1.c patching file gcc/gcc/config/i386/cygwin2.c patching file gcc/gcc/config/i386/t-cygming patching file gcc/gcc/config/i386/w32-shared-ptr-globls.c patching file gcc/gcc/config/i386/w32-shared-ptr-init.c -- -- Jerry van Dijk | email: jv...@at... -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk |
From: Thomas P. <tp...@gm...> - 2002-11-20 10:58:18
|
Danny, in the meantime i have played around with sjlj exceptions handling and created a new w32-shared-ptr handling. I have encountered several problems that are solved by my changes: 1. cross dll/exe sjlj exceptions are now supported and do not require any runtime changes to either mingw nor cygwin. 2. The atom name is recreated after a fork on cygwin to avoid problems with dynamically loaded dlls. 3. The atom name has been changed to reflect the exception model, thread exception type and system. What would happen when a cygwin app would load a mingw dll and vice versa or you would mix dlls and apps that have been created with different thread model types ? 4. The globals vars stuff has been reviewed and changed (IMHO to a cleaner solution by adding a w32-shared-ptr.h file in config/i386. 5. The atom name creation and evaluation has been changed. 6. The atom initialization has been made thread safe (this might not be important but it doesn't hurt). I have attached my patches to unwind-sjlj.c, unwind-dw2-fde.c and a new w32-shared-ptr.c and w32-shared-ptr.h file. The patches were made against cygwin gcc-3.2-3 but should apply to other gcc versions as well. Comments are welcome, i will write a Changelog on request. Greetings, Thomas On Wed, 20 Nov 2002, Danny Smith wrote: > > I just had a look at unwind-sjl.c, i would suggest > > > > static struct SjLj_Function_Context *fc_static; > > static __gthread_key_t fc_key; > > static int use_fc_key = -1; > > > > and once in fc_key_init_once to be in shared memory. > > > > I've add the sjlj gthread variables to the shared pointer machinery > using your organization of the pointers into a structure. > > For now, I initilialise both Dwarf2 and SJLJ ptrs so that I can use the > same startup code for both Dwarf2 and sjlj GCC builds.. If wanted, the > ones we don't use could be ifdef out with builtin define > ___USING_SJLJ_EXCEPTIONS. > > Note that these pointers have to be initialized before main, since main > can throw exceptions and it needs the eh objects in its prologue. > Hence, explicit call of __w32_sharedptr_initialize in startup code > rather than using constructor mechnism. > > I have split things up so that new GCC builds can work with old > mingw/cygwin runtime. The global pointers get defined in extern file so > that even if runtime does not call __w32_sharedptr_initialize they are > still allocated. > > I have also added a dummy __w32_sharedptr_initialize to libmingwex.a for > mingw, to avoid undefined reference when using the new mingw runtime > with gcc-2.95. An alterrnative would be add the dummy to 2.95's > libgcc.a > > I haven't done much testing at all with threads and exceptions, but at > least it still works okay in single-thread tests, both SJLJ and DW2 > (modulo the stack corruption problem > with -fomit-frame-pointer/__stdcall/-mno-accumulate-outgoing-args and > DW2). If testing DW2, be sure -march < i686, since i686 turns > on -maccumulate-outgoing-args. > > I haven't looked at how to incorporate in Cygwin dll. Nor have I used > the *__get_w32_eh_sharedptr() approach for mingw. > > Attached are diffs against GCC3.3 (C and C++ only) and against > mingw-runtime. The GCC diffs have a lot of other modifications as well. > Tell me if you have problems pulling out the EH specific stuff from the > rest. > > > Danny > > |
From: Danny S. <dan...@cl...> - 2002-11-20 19:38:37
|
Thanks Thomas! I will test with gc3.3 I assume you are using the ctor mechanism in crtstuff to call the inialization function as in 3.2. Have you you tried with throwing and catching sjlj exceptions in user's main()? Secondly , there is static " emergency_mutex" libsupc++/eh_alloc.cc and static __cxa_eh_globals globals_static in eh_globals.cc. Each with associated 'once' for __GTHREAD_MUTEX_INIT_FUNCTION Danny ----- Original Message ----- From: "Thomas Pfaff" <tp...@gm...> To: <min...@li...> Sent: Wednesday, 20 November 2002 10:57 Subject: Re: Re [2]: [MinGW-dvlpr] Re: Exception handling in gcc-3 > > Danny, > > in the meantime i have played around with sjlj exceptions handling and > created a new w32-shared-ptr handling. > > I have encountered several problems that are solved by my changes: > > 1. cross dll/exe sjlj exceptions are now supported and do not require any > runtime changes to either mingw nor cygwin. > 2. The atom name is recreated after a fork on cygwin to avoid problems > with dynamically loaded dlls. > 3. The atom name has been changed to reflect the exception model, > thread exception type and system. What would happen when a cygwin app > would load a mingw dll and vice versa or you would mix dlls and apps that > have been created with different thread model types ? > 4. The globals vars stuff has been reviewed and changed (IMHO to a cleaner > solution by adding a w32-shared-ptr.h file in config/i386. > 5. The atom name creation and evaluation has been changed. > 6. The atom initialization has been made thread safe (this might not be > important but it doesn't hurt). > > I have attached my patches to unwind-sjlj.c, unwind-dw2-fde.c > and a new w32-shared-ptr.c and w32-shared-ptr.h file. > The patches were made against cygwin gcc-3.2-3 but should apply to other > gcc versions as well. > > Comments are welcome, i will write a Changelog on request. > > Greetings, > > Thomas > > |
From: Danny S. <dan...@cl...> - 2002-11-20 22:07:14
|
I have answered my own question about main. Thanks very much Thomas, this is really much cleaner than my clumsy efforts and it avoids all the problems with runtime compatability. I have made a few minor changes to crtstuff so that it doesn't drag in unwind-dw2-fde.o when __USING_SJLJ_EXCEPTIONS__, It may be simpler to do the #include "w32-shared-ptr.h" from target header cygming.h. We will probably need to neutralize the "w32" business with new TARGET_SHARED_PTR macros that could also be defined in w32-shared-ptr.h or in cygming.h. Once we do that it should be submitted as patch, for 3.4 when it opens or BIB. Thomas, could you post a changelog for your work.? Chris, have you had a chance to look at this? I've only done testing with 3.3, but I foresee no problem with getting this working with 3.2.1. If mingw is going to release binaries for 3.2.1, I think it should be with SJLJ. Thanks again Thomas Jerry and other who might have tried my attempt, please throw it in the rubbish. Danny ----- Original Message ----- From: "Danny Smith" <dan...@cl...> To: <min...@li...>; <tp...@gm...> Sent: Wednesday, 20 November 2002 19:36 Subject: Re: Re [2]: [MinGW-dvlpr] Re: Exception handling in gcc-3 > Thanks Thomas! I will test with gc3.3 I assume you are using the ctor > mechanism in crtstuff to call the inialization function as in 3.2. Have > you you tried with throwing and catching sjlj exceptions in user's > main()? Secondly , there is static " emergency_mutex" > libsupc++/eh_alloc.cc and static __cxa_eh_globals globals_static in > eh_globals.cc. Each with associated 'once' for > __GTHREAD_MUTEX_INIT_FUNCTION > > Danny > > |
From: Danny S. <dan...@cl...> - 2002-11-20 03:59:30
|
----- Original Message ----- From: "Jerry van Dijk" <jv...@at...> To: <min...@li...> Cc: <tp...@gm...> Sent: Wednesday, 20 November 2002 03:02 Subject: Re: Re [2]: [MinGW-dvlpr] Re: Exception handling in gcc-3 > mingw patch went OK, but gcc gave problems, see log below. Do I have to apply > this patch to a clean checkout of gcc ? > Yes. That would probably be cleaner since that is how I generated the diffs. Danny |
From: Jerry v. D. <jv...@at...> - 2002-11-20 14:33:34
|
Danny Smith writes: > > mingw patch went OK, but gcc gave problems, see log below. Do I have > to apply > > this patch to a clean checkout of gcc ? > > Yes. That would probably be cleaner since that is how I generated the > diffs. Ok, that worked. Now the new mingw build fails: gcc.exe -c -O2 -fomit-frame-pointer -I../../../mingw/mingwex -I../../../mi ngw/mingwex/../include -I../../../mingw/mingwex/../../w32api/include -nostdinc -nostdinc++ -iwithprefixbefore include ../../../mingw/mingwex/mingw-fseek.c -o mingw-fseek.o make.exe[2]: *** No rule to make target `w32-shared-ptrs-dummy.o', needed by `l ibmingwex.a'. Stop. make.exe[2]: Leaving directory `C:/home/src/winsup/build/mingw/mingwex' make.exe[1]: *** [mingwex] Error 1 make.exe[1]: Leaving directory `C:/home/src/winsup/build/mingw' make: *** [all] Error 2 -- -- Jerry van Dijk | email: jv...@at... -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk |