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

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Doug> Hi.  My limited knowledge didn't find anything seriously broken 1/2
Doug> :-), but I do have a few comments.

Thanks!

Doug> To that end, should gdb print a warning if _Unwind_DebugHook isn't found?
Doug> Your patch isn't alone in this, and I'm not sure when and how to print
Doug> such warnings.

I wonder about this as well.

Adding a warning in this case is a bit unusual, in that many programs
do not use exceptions.  E.g., getting this warning when debugging an
ordinary C program would seem weird.  Maybe there is some way around
that.

Doug> [To minimize the verbosity, gdb could print a general warning when it
Doug> detects such conditions, with instructions on how to get further
Doug> details.  E.g. "GDB has detected conditions that will hinder some
Doug> debugging efforts.  Use `mumble' for further information." or some
Doug> such.

Yeah.  We could add useful text in "help" somewhere.  Maybe "help faq".

Doug> That way the user might just get one warning at startup, and
Doug> that's it.

... once per affected inferior, I think.

Doug> The high order bit though is that there would be standard things the
Doug> user can do to figure out why (e.g. in this case) "next" isn't working
Doug> the way s/he is expecting it to (for typically frequent cases that are
Doug> reasonable to handle - stripped libpthread anyone?).

I like this idea.

Tom> @@ -6356,6 +6403,7 @@ struct until_break_command_continuation_args
Tom> Â{
Tom> Â struct breakpoint *breakpoint;
Tom> Â struct breakpoint *breakpoint2;
Tom> + Âint thread_num;
Tom> Â};

Doug> Having to record the thread here seems orthogonal to handling next-ing
Doug> over exceptions (e.g. why isn't it also required for longjmp?).

IIRC, the longjmp code works for 'next' but not for 'until' (at least,
my recollection is that longjmp does not work for all these commands;
I don't remember exactly which ones).

The reason this field is here is so that we can delete the exception
breakpoint when cleaning up after the 'until'.  The exception
breakpoints are all thread-specific; recording the thread number is
convenient since we already have delete_longjmp_breakpoint.

Doug> Maybe add further comments explaining what's going on here?

Will do.

Tom> + Â Â Â/* We're going to replace the current step-resume breakpoint
Tom> + Â Â Â Âwith a longjmp-resume breakpoint. Â*/

Doug> s/longjmp/exception/  ?

Oops, thanks.

Tom> + Â Â Â Â if (!SYMBOL_IS_ARGUMENT (sym))
Tom> + Â Â Â Â Â continue;

Doug> It's a bit odd to check function arguments for something like this.
Doug> But maybe I just don't understand the implementation enough.

Doug> There's an implementation aspect here that's not clear to me.
Doug> Can you add comments elaborating on the argno == 0 vs argno > 0 cases?

I will add a comment.  Meanwhile, here's the explanation.

I added a function to the unwinder:

    /* This function is called during unwinding.  It is intended as a hook
       for a debugger to intercept exceptions.  CFA is the CFA of the
       target frame.  HANDLER is the PC to which control will be
       transferred.  */
    static void
    _Unwind_DebugHook (void *cfa __attribute__ ((__unused__)),
                       void *handler __attribute__ ((__unused__)))

At 'next' time, gdb sets the "exception breakpoint" on this function.
To use it, gdb then examines the arguments to the function.  If the
target frame, as represented by the CFA argument, is interesting
(e.g., for 'next', somewhere in the current frame or above), then we
set a temporary breakpoint at HANDLER.

Doug> Blech.  I haven't been paying attention to this myself.
Doug> It's really nice to be able to add new testcases *without* having to
Doug> edit any files like Makefile.in.

Yes, I also am not a fan of this, or for that matter of the testsuite
configure script and all the testsuite/*/Makefile.in files.  I don't
have an alternate proposal right now, though.

Tom