This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 2/2] Assert leftover cleanups in TRY_CATCH
- From: Doug Evans <dje at google dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Mon, 6 May 2013 21:37:08 -0700
- Subject: Re: [patch 2/2] Assert leftover cleanups in TRY_CATCH
- References: <20130501165750 dot GA453 at host2 dot jankratochvil dot net> <87obcoyot3 dot fsf at fleche dot redhat dot com> <20130506181832 dot GA23882 at host2 dot jankratochvil dot net> <878v3symbc dot fsf at fleche dot redhat dot com> <20130507014724 dot GA14170 at host2 dot jankratochvil dot net>
On Mon, May 6, 2013 at 6:47 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Mon, 06 May 2013 20:50:47 +0200, Tom Tromey wrote:
>> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
>> Jan> C++ exceptions solve it all, everyone knows it, it is simple,
>> Jan> effective and at least in comparison with the existing GDB system
>> Jan> it is foolproof.
>>
>> I know, and I agree that it would yield a better gdb, but I don't think
>> it is going to happen.
>
> I can't seriously reply these questions anymore. GCC already requires C++ so
> why GDB cannot? I do not remember any valid reason against C++ from all the
> GDB discussions around it.
>
> GDB still is barely usable for real C++ application debugging, debugging
> multiple virtual class inheritance does not work, one has to use printfs
> instead. Inferior breakpoint with conditional to stop only after thousands of
> iterations is so unusably slow it is faster to rebuild the inferior with the
> conditional put into inferior's source. etc. etc.
I'm not going to enter an opinion of C over C++ here,
but I don't see how inferior breakpoint slowness is related.
[I can imagine a reason why multiple virtual class inheritance is related,
but then again I'm not sure I'd want to see gdb use it itself.]
btw, is the slowness just an all-stop thing?
Or is there room for massive improvement in non-stop too?