This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 00/11] C++/MinGW patches
- From: Pedro Alves <palves at redhat dot com>
- To: fracting at gmail dot com
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 03 Nov 2015 22:39:48 +0000
- Subject: Re: [PATCH 00/11] C++/MinGW patches
- Authentication-results: sourceware.org; auth=none
- References: <1446492970-21432-1-git-send-email-palves at redhat dot com> <5637C1FA dot 2060708 at redhat dot com> <CALd+sZThHQQFq4DSw9Dd0pXVfYmAq=RFj0GM1OtmSXv8OwL4sg at mail dot gmail dot com> <5637CB96 dot 4010106 at redhat dot com> <CALd+sZQ2tPkgiKAH2rxpLy_pr_j4cxTo2Jy95naFG6LuoJP2GQ at mail dot gmail dot com> <5638988C dot 5070601 at redhat dot com> <5638E6C5 dot 5040006 at redhat dot com> <CALd+sZQmrVgosOuz+qOnHZe6p4k8Oyuv2qNWbjXm9svyHTJ+3A at mail dot gmail dot com>
On 11/03/2015 09:02 PM, Qian Hong wrote:
> On Wed, Nov 4, 2015 at 12:54 AM, Pedro Alves <palves@redhat.com> wrote:
>> I've pushed this patch:
>>
>> https://sourceware.org/ml/gdb-patches/2015-11/msg00114.html
>>
>> on the testing branch as well. I wonder if it makes a difference for you.
>
> Update:
>
> I can confirm this patch fix the issue for MSYS2 mingw-w64 gdb.
>
> I was testing the wrong binary due to frequently switch between
> Windows VM and Linux host.
> Sorry for the stupid mistake and noise.
No worries, and thanks for reconfirming.
Note however, that the patch will be reverted at some point. It's
a workaround until we get rid of exceptions thrown from signal
handlers, but, Windows doesn't really have unix-like async signal
handlers (signal handlers run on a separate thread), so it should
be unaffected by that issue.
>From the backtrace you showed:
(gdb) bt
#0 0x00870778 in abort ()
#1 0x0085ebda in uw_init_context_1 ()
#2 0x0085f2de in _Unwind_RaiseException ()
#3 0x008728e5 in __cxa_throw ()
#4 0x006cfead in throw_exception (exception=...)
at ../../gdb/gdb/common/common-exceptions.c:295
#5 0x006d000d in throw_it (reason=RETURN_ERROR, error=GENERIC_ERROR,
fmt=0x8d86bc <filename_display_kind_names+52> "No symbol table is loaded. Use the \"file\" command.", ap=0x320f754 "~aP")
at ../../gdb/gdb/common/common-exceptions.c:354
#6 0x006d0034 in throw_verror (error=GENERIC_ERROR,
fmt=0x8d86bc <filename_display_kind_names+52> "No symbol table is loaded. Use the \"file\" command.", ap=0x320f754 "~aP")
at ../../gdb/gdb/common/common-exceptions.c:360
#7 0x0068c1f6 in verror (
string=<error reading variable: Could not find the frame base for "verror(char const*, char*)".>,
args=<error reading variable: Could not find the frame base for "verror(char const*, char*)".>) at ../../gdb/gdb/utils.c:525
#8 0x006cfc77 in error (
fmt=0x8d86bc <filename_display_kind_names+52> "No symbol table is loaded. Use the \"file\" command.") at ../../gdb/gdb/common/errors.c:43
#9 0x0050c964 in set_default_source_symtab_and_line ()
at ../../gdb/gdb/source.c:207
#10 0x00474fa0 in list_command (
...
We see that gdb was throwing a gdb exception from mainline code,
not a signal handler, and in frame #4, gdb called the runtime to throw
the (underlying) C++ exception. Line common-exceptions.c:295 is just "throw ex;"
So it seems to me that something is wrong with C++ exceptions
support in the mingw toolchain you used. I suggest trying a simple
test like:
int
main ()
{
try
{
throw 1;
}
catch(...)
{
}
return 0;
}
... to check whether C++ exceptions work at all.
One issue to look out for is what flavor of C++ exceptions your mingw
toolchain uses. There are flavors using dwarf2, others using sjlj. Also, we
link gdb with -static-libstdc++ -static-libgcc, which may make a difference.
Thanks,
Pedro Alves