From: SourceForge.net <no...@so...> - 2005-05-30 07:55:47
|
Bugs item #1211187, was opened at 2005-05-30 07:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1211187&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oliver Stoeneberg (kidkat) Assigned to: Nobody/Anonymous (nobody) Summary: -pg causes wrong-code generation with FASTCALL Initial Comment: The resulting executable will crash when compiled with "-pg". typedef struct STRING_POOL { int a; } STRING_POOL; typedef struct XML_Memory_Handling_Suite { int t; } XML_Memory_Handling_Suite; #define FASTCALL __attribute__((stdcall, regparm(3))) static void FASTCALL poolInit(STRING_POOL *pool, const XML_Memory_Handling_Suite *ms) { pool->a = 1; } int main(void) { STRING_POOL a; XML_Memory_Handling_Suite d; poolInit(&a, &d); } Here is the backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0040e456 in poolInit (pool=0x40e44d, ms=0x0) at src/expat/xmlparse.c:5874 5874 pool->blocks = NULL; (gdb) bt #0 0x0040e456 in poolInit (pool=0x40e44d, ms=0x0) at src/expat/xmlparse.c:5874 #1 0x0040d339 in dtdCreate (ms=0x3f2554) at src/expat/xmlparse.c:5428 #2 0x00403193 in parserCreate (encodingName=0x0, memsuite=0x0, nameSep=0x0, dtd=0x0) at src/expat/xmlparse.c:737 #3 0x00402fb7 in XML_ParserCreate_MM (encodingName=0x0, memsuite=0x0, nameSep=0x0) at src/expat/xmlparse.c:671 #4 0x00402f4b in XML_ParserCreate (encodingName=0x0) at src/expat/xmlparse.c:648 #5 0x00402b7c in process (is=0x7803a690, os=0x7803a6b0) at src/xml2info.c:766 #6 0x00402efe in main (argc=1, argv=0x3f24c8) at src/xml2info.c:835 Taken from GCC bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1211187&group_id=2435 |
From: SourceForge.net <no...@so...> - 2005-05-31 00:03:25
|
Bugs item #1211187, was opened at 2005-05-30 19:55 Message generated for change (Comment added) made by dannysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1211187&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oliver Stoeneberg (kidkat) Assigned to: Nobody/Anonymous (nobody) Summary: -pg causes wrong-code generation with FASTCALL Initial Comment: The resulting executable will crash when compiled with "-pg". typedef struct STRING_POOL { int a; } STRING_POOL; typedef struct XML_Memory_Handling_Suite { int t; } XML_Memory_Handling_Suite; #define FASTCALL __attribute__((stdcall, regparm(3))) static void FASTCALL poolInit(STRING_POOL *pool, const XML_Memory_Handling_Suite *ms) { pool->a = 1; } int main(void) { STRING_POOL a; XML_Memory_Handling_Suite d; poolInit(&a, &d); } Here is the backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0040e456 in poolInit (pool=0x40e44d, ms=0x0) at src/expat/xmlparse.c:5874 5874 pool->blocks = NULL; (gdb) bt #0 0x0040e456 in poolInit (pool=0x40e44d, ms=0x0) at src/expat/xmlparse.c:5874 #1 0x0040d339 in dtdCreate (ms=0x3f2554) at src/expat/xmlparse.c:5428 #2 0x00403193 in parserCreate (encodingName=0x0, memsuite=0x0, nameSep=0x0, dtd=0x0) at src/expat/xmlparse.c:737 #3 0x00402fb7 in XML_ParserCreate_MM (encodingName=0x0, memsuite=0x0, nameSep=0x0) at src/expat/xmlparse.c:671 #4 0x00402f4b in XML_ParserCreate (encodingName=0x0) at src/expat/xmlparse.c:648 #5 0x00402b7c in process (is=0x7803a690, os=0x7803a6b0) at src/xml2info.c:766 #6 0x00402efe in main (argc=1, argv=0x3f24c8) at src/xml2info.c:835 Taken from GCC bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810 ---------------------------------------------------------------------- >Comment By: Danny Smith (dannysmith) Date: 2005-05-31 12:03 Message: Logged In: YES user_id=11494 Confirmed, There are two ways to fix this: 1) Add some inline asm to current code in profile/profile.h to save and restore caller-clobbered registers. This hack is a bit fragile since it depeds on the the real _mcount in mcount.c always being inlined into mcount. That can be ensured with new gcc __attribute__ ((always_inline)), but not with 2.95. So, it would need some GCC version check quards around the new additions. 2) A more robust fix that replaces the macro definintion of mscount with an assembly stub that calls an external _mcount. This is the way that glibc does it and in fact, the assembly code, as simple as it is, would inherit the LGPL copyright of the source that I looked at. Maybe this is not a major issue since profiled exe's are already under the Cygwin license due to the code in profil.h. Both of these also require a trivial patch to gcc to prevent unnecessary use of %edx to store profile counters Any comments? Danny ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1211187&group_id=2435 |
From: SourceForge.net <no...@so...> - 2005-05-31 15:30:28
|
Bugs item #1211187, was opened at 2005-05-30 07:55 Message generated for change (Comment added) made by kidkat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1211187&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oliver Stoeneberg (kidkat) Assigned to: Nobody/Anonymous (nobody) Summary: -pg causes wrong-code generation with FASTCALL Initial Comment: The resulting executable will crash when compiled with "-pg". typedef struct STRING_POOL { int a; } STRING_POOL; typedef struct XML_Memory_Handling_Suite { int t; } XML_Memory_Handling_Suite; #define FASTCALL __attribute__((stdcall, regparm(3))) static void FASTCALL poolInit(STRING_POOL *pool, const XML_Memory_Handling_Suite *ms) { pool->a = 1; } int main(void) { STRING_POOL a; XML_Memory_Handling_Suite d; poolInit(&a, &d); } Here is the backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0040e456 in poolInit (pool=0x40e44d, ms=0x0) at src/expat/xmlparse.c:5874 5874 pool->blocks = NULL; (gdb) bt #0 0x0040e456 in poolInit (pool=0x40e44d, ms=0x0) at src/expat/xmlparse.c:5874 #1 0x0040d339 in dtdCreate (ms=0x3f2554) at src/expat/xmlparse.c:5428 #2 0x00403193 in parserCreate (encodingName=0x0, memsuite=0x0, nameSep=0x0, dtd=0x0) at src/expat/xmlparse.c:737 #3 0x00402fb7 in XML_ParserCreate_MM (encodingName=0x0, memsuite=0x0, nameSep=0x0) at src/expat/xmlparse.c:671 #4 0x00402f4b in XML_ParserCreate (encodingName=0x0) at src/expat/xmlparse.c:648 #5 0x00402b7c in process (is=0x7803a690, os=0x7803a6b0) at src/xml2info.c:766 #6 0x00402efe in main (argc=1, argv=0x3f24c8) at src/xml2info.c:835 Taken from GCC bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810 ---------------------------------------------------------------------- >Comment By: Oliver Stoeneberg (kidkat) Date: 2005-05-31 15:30 Message: Logged In: YES user_id=591019 Well...I got nothing to say about this, as I don't really know anything about the internal stuff. But I guess the second way would the better one. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2005-05-31 00:03 Message: Logged In: YES user_id=11494 Confirmed, There are two ways to fix this: 1) Add some inline asm to current code in profile/profile.h to save and restore caller-clobbered registers. This hack is a bit fragile since it depeds on the the real _mcount in mcount.c always being inlined into mcount. That can be ensured with new gcc __attribute__ ((always_inline)), but not with 2.95. So, it would need some GCC version check quards around the new additions. 2) A more robust fix that replaces the macro definintion of mscount with an assembly stub that calls an external _mcount. This is the way that glibc does it and in fact, the assembly code, as simple as it is, would inherit the LGPL copyright of the source that I looked at. Maybe this is not a major issue since profiled exe's are already under the Cygwin license due to the code in profil.h. Both of these also require a trivial patch to gcc to prevent unnecessary use of %edx to store profile counters Any comments? Danny ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1211187&group_id=2435 |
From: SourceForge.net <no...@so...> - 2005-06-03 22:10:18
|
Bugs item #1211187, was opened at 2005-05-30 19:55 Message generated for change (Comment added) made by dannysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1211187&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oliver Stoeneberg (kidkat) Assigned to: Nobody/Anonymous (nobody) Summary: -pg causes wrong-code generation with FASTCALL Initial Comment: The resulting executable will crash when compiled with "-pg". typedef struct STRING_POOL { int a; } STRING_POOL; typedef struct XML_Memory_Handling_Suite { int t; } XML_Memory_Handling_Suite; #define FASTCALL __attribute__((stdcall, regparm(3))) static void FASTCALL poolInit(STRING_POOL *pool, const XML_Memory_Handling_Suite *ms) { pool->a = 1; } int main(void) { STRING_POOL a; XML_Memory_Handling_Suite d; poolInit(&a, &d); } Here is the backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0040e456 in poolInit (pool=0x40e44d, ms=0x0) at src/expat/xmlparse.c:5874 5874 pool->blocks = NULL; (gdb) bt #0 0x0040e456 in poolInit (pool=0x40e44d, ms=0x0) at src/expat/xmlparse.c:5874 #1 0x0040d339 in dtdCreate (ms=0x3f2554) at src/expat/xmlparse.c:5428 #2 0x00403193 in parserCreate (encodingName=0x0, memsuite=0x0, nameSep=0x0, dtd=0x0) at src/expat/xmlparse.c:737 #3 0x00402fb7 in XML_ParserCreate_MM (encodingName=0x0, memsuite=0x0, nameSep=0x0) at src/expat/xmlparse.c:671 #4 0x00402f4b in XML_ParserCreate (encodingName=0x0) at src/expat/xmlparse.c:648 #5 0x00402b7c in process (is=0x7803a690, os=0x7803a6b0) at src/xml2info.c:766 #6 0x00402efe in main (argc=1, argv=0x3f24c8) at src/xml2info.c:835 Taken from GCC bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810 ---------------------------------------------------------------------- >Comment By: Danny Smith (dannysmith) Date: 2005-06-04 10:10 Message: Logged In: YES user_id=11494 Actually, this bug affect more than just functions labeled with regpoarm or __fastcall attribute. With -funit-at-a-time optimization (enabled by default at-O2) non-inlineable local functions use regparm calling convention: eg: this: static void __attribute__((noinline)) InitB(int* a, int *b) { *b = *a; } gets coded as: _InitB: pushl %ebp movl %esp, %ebp popl %ebp movl (%eax), %eax movl %eax, (%edx) ret ---------------------------------------------------------------------- Comment By: Oliver Stoeneberg (kidkat) Date: 2005-06-01 03:30 Message: Logged In: YES user_id=591019 Well...I got nothing to say about this, as I don't really know anything about the internal stuff. But I guess the second way would the better one. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2005-05-31 12:03 Message: Logged In: YES user_id=11494 Confirmed, There are two ways to fix this: 1) Add some inline asm to current code in profile/profile.h to save and restore caller-clobbered registers. This hack is a bit fragile since it depeds on the the real _mcount in mcount.c always being inlined into mcount. That can be ensured with new gcc __attribute__ ((always_inline)), but not with 2.95. So, it would need some GCC version check quards around the new additions. 2) A more robust fix that replaces the macro definintion of mscount with an assembly stub that calls an external _mcount. This is the way that glibc does it and in fact, the assembly code, as simple as it is, would inherit the LGPL copyright of the source that I looked at. Maybe this is not a major issue since profiled exe's are already under the Cygwin license due to the code in profil.h. Both of these also require a trivial patch to gcc to prevent unnecessary use of %edx to store profile counters Any comments? Danny ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1211187&group_id=2435 |
From: SourceForge.net <no...@so...> - 2005-06-18 06:10:49
|
Bugs item #1211187, was opened at 2005-05-30 19:55 Message generated for change (Comment added) made by dannysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1211187&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Later Priority: 5 Submitted By: Oliver Stoeneberg (kidkat) Assigned to: Nobody/Anonymous (nobody) Summary: -pg causes wrong-code generation with FASTCALL Initial Comment: The resulting executable will crash when compiled with "-pg". typedef struct STRING_POOL { int a; } STRING_POOL; typedef struct XML_Memory_Handling_Suite { int t; } XML_Memory_Handling_Suite; #define FASTCALL __attribute__((stdcall, regparm(3))) static void FASTCALL poolInit(STRING_POOL *pool, const XML_Memory_Handling_Suite *ms) { pool->a = 1; } int main(void) { STRING_POOL a; XML_Memory_Handling_Suite d; poolInit(&a, &d); } Here is the backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0040e456 in poolInit (pool=0x40e44d, ms=0x0) at src/expat/xmlparse.c:5874 5874 pool->blocks = NULL; (gdb) bt #0 0x0040e456 in poolInit (pool=0x40e44d, ms=0x0) at src/expat/xmlparse.c:5874 #1 0x0040d339 in dtdCreate (ms=0x3f2554) at src/expat/xmlparse.c:5428 #2 0x00403193 in parserCreate (encodingName=0x0, memsuite=0x0, nameSep=0x0, dtd=0x0) at src/expat/xmlparse.c:737 #3 0x00402fb7 in XML_ParserCreate_MM (encodingName=0x0, memsuite=0x0, nameSep=0x0) at src/expat/xmlparse.c:671 #4 0x00402f4b in XML_ParserCreate (encodingName=0x0) at src/expat/xmlparse.c:648 #5 0x00402b7c in process (is=0x7803a690, os=0x7803a6b0) at src/xml2info.c:766 #6 0x00402efe in main (argc=1, argv=0x3f24c8) at src/xml2info.c:835 Taken from GCC bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810 ---------------------------------------------------------------------- >Comment By: Danny Smith (dannysmith) Date: 2005-06-18 18:10 Message: Logged In: YES user_id=11494 This is fixed in mingw runtime. The gcc part of the fix is in trunk (gcc.4.1). I'll backport the gcc one-liner to next mingw gcc RC Danny ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2005-06-04 10:10 Message: Logged In: YES user_id=11494 Actually, this bug affect more than just functions labeled with regpoarm or __fastcall attribute. With -funit-at-a-time optimization (enabled by default at-O2) non-inlineable local functions use regparm calling convention: eg: this: static void __attribute__((noinline)) InitB(int* a, int *b) { *b = *a; } gets coded as: _InitB: pushl %ebp movl %esp, %ebp popl %ebp movl (%eax), %eax movl %eax, (%edx) ret ---------------------------------------------------------------------- Comment By: Oliver Stoeneberg (kidkat) Date: 2005-06-01 03:30 Message: Logged In: YES user_id=591019 Well...I got nothing to say about this, as I don't really know anything about the internal stuff. But I guess the second way would the better one. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2005-05-31 12:03 Message: Logged In: YES user_id=11494 Confirmed, There are two ways to fix this: 1) Add some inline asm to current code in profile/profile.h to save and restore caller-clobbered registers. This hack is a bit fragile since it depeds on the the real _mcount in mcount.c always being inlined into mcount. That can be ensured with new gcc __attribute__ ((always_inline)), but not with 2.95. So, it would need some GCC version check quards around the new additions. 2) A more robust fix that replaces the macro definintion of mscount with an assembly stub that calls an external _mcount. This is the way that glibc does it and in fact, the assembly code, as simple as it is, would inherit the LGPL copyright of the source that I looked at. Maybe this is not a major issue since profiled exe's are already under the Cygwin license due to the code in profil.h. Both of these also require a trivial patch to gcc to prevent unnecessary use of %edx to store profile counters Any comments? Danny ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1211187&group_id=2435 |