This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: next/finish/etc -vs- exceptions

>>>>> "Jan" == Jan Kratochvil <> 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

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]