This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: next/finish/etc -vs- exceptions
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 30 Nov 2010 09:43:28 -0700
- Subject: Re: RFC: next/finish/etc -vs- exceptions
- References: <m38w2a236l.fsf@fleche.redhat.com> <20101125075847.GA19270@host0.dyn.jankratochvil.net>
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Thanks for the review.
I've made most of the changes you recommended.
>> * breakpoint.h (enum bptype) <bp_exception, bp_exception_resume,
>> bp_exception_master> : New constants.
Jan> Therefore it is a precent new `bptype's are permitted instead of using
Jan> breakpoint_ops (which may need some extensions, not sure).
Yeah. Mostly I just copied and then extended the existing longjmp
support.
I looked briefly at using breakpoint_ops, but it seems like it would
require a bunch of new methods that are specific to just this
breakpoint. Maybe that is the way to go?
Jan> BTW the testcase does not work on neither ppc32 nor on ppc64.
Thanks, I will investigate.
Jan> tp-> initiating_frame should be initialized from
Jan> set_longjmp_breakpoint, as it is required for that operation.
I made this change.
Jan> It probably should not be placed in TP. If we are
Jan> stepping/until-ing/etc. some code and execute some breakpoint's
Jan> command list trying to step/next/etc. again already from a
Jan> different frame it won't work. But this is a problem for most of
Jan> the TP variables already so that's OK for this patch. It should be
Jan> carried over from the set-breakpoint to resume-breakpoint
Jan> otherwise.
I thought that gdb did not support nested inferior-control commands like
this.
It would be a nice feature.
>> + add_continuation (tp, until_next_continuation, tp, NULL);
Jan> continuation_free_args is NULL here but I think the breakpoint
Jan> should get deleted even if there is some premature thread deletion.
Jan> But maybe just all the breakpoints specific for that thread
Jan> (clear_thread_inferior_resources) should be deleted which would
Jan> also solve this problem?
I will try to make a test case so I can see what actually happens in
this scenario. Thanks for pointing it out.
>> +if { [compile_java_from_source ${srcdir}/$subdir/${srcfile} ${binfile} "-g"] != "" } {
>> + untested "Couldn't compile ${srcdir}/$subdir/${srcfile}"
>> + return -1
Jan> maybe prepare_for_testing?
Jan> (nitpick)
I left this as-is. compile_java_from_source does some extra processing
right now.
Tom