Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: RFC: next/finish/etc -vs- exceptions
Date: Wed, 24 Nov 2010 17:53:00 -0000	[thread overview]
Message-ID: <20101124175316.GA2634@adacore.com> (raw)
In-Reply-To: <m38w2a236l.fsf@fleche.redhat.com>

> I'd appreciate comments.  I don't want to commit this without a review,
> as my experience is that I usually err when touching breakpoints or
> infrun.

Outch - no feedback as far as I can tell since the patch as posted
something like 6 weeks ago :-(.  We are all so busy these days...
When that happens, I suggest we avoid being too conservative on the HEAD,
especially this far before the next branch creation.  If you've already
had Pedro's comments and you think you addressed them, how about going
ahead? We can always revert later on...

> 2010-10-06  Tom Tromey  <tromey@redhat.com>
> 
> 	* infrun.c (handle_inferior_event): Handle exception breakpoints.
> 	(handle_inferior_event): Likewise.
> 	(insert_exception_resume_breakpoint): New function.
> 	(check_exception_resume): Likewise.
> 	* inferior.h (delete_longjmp_breakpoint_cleanup): Declare.
> 	* infcmd.c (delete_longjmp_breakpoint_cleanup): No longer static.
> 	(step_1): Set thread's initiating frame.
> 	(until_next_continuation): New function.
> 	(until_next_command): Support exception breakpoints.
> 	(finish_command_continuation): Delete longjmp breakpoint.
> 	(finish_forward): Support exception breakpoints.
> 	* gdbthread.h (struct thread_info) <initiating_frame>: New field.
> 	* breakpoint.h (enum bptype) <bp_exception, bp_exception_resume,
> 	bp_exception_master>: New constants.
> 	(struct bpstat_what) <is_longjmp>: New field.
> 	* breakpoint.c (create_exception_master_breakpoint): New function.
> 	(update_breakpoints_after_exec): Handle bp_exception_master.  Call
> 	create_exception_master_breakpoint.
> 	(print_it_typical): Handle bp_exception_master, bp_exception.
> 	(bpstat_stop_status): Handle bp_exception_master.
> 	(bpstat_what): Handle bp_exception_master, bp_exception,
> 	bp_exception_resume.
> 	(bptype_string): Likewise.
> 	(print_one_breakpoint_location): Likewise.
> 	(allocate_bp_location): Likewise.
> 	(set_longjmp_breakpoint): Handle exception breakpoints.
> 	(delete_longjmp_breakpoint): Likewise.
> 	(mention): Likewise.
> 	(struct until_break_command_continuation_args) <thread_num>: New
> 	field.
> 	(until_break_command_continuation): Call
> 	delete_longjmp_breakpoint.
> 	(until_break_command): Support exception breakpoints.
> 	(delete_command): Likewise.
> 	(breakpoint_re_set_one): Likewise.
> 	(breakpoint_re_set): Likewise.
> 
> 2010-10-06  Tom Tromey  <tromey@redhat.com>
> 
> 	* gdb.java/jnpe.java: New file.
> 	* gdb.java/jnpe.exp: New file.
> 	* gdb.cp/gdb9593.exp: New file.
> 	* gdb.cp/gdb9593.cc: New file.

I started reviewing the patch, and quickly realized that this is
flying way over my head, and would require a significant amount
of time for me to really understand...

I did notice a couple of tiny details, though:

> +    case bp_exception_master:
> +      /* These should never be enabled.  */
> +      printf_filtered (_("Exception Master Breakpoint: gdb should not stop!\n"));
> +      result = PRINT_NOTHING;
> +      break;

I understand that an assert or internal-error would be unnecessarily
catastrophic for the user, but how about a warning instead? (just a
thought - this is really cosmetic)

> +
> +    /* Used for BPSTAT_WHAT_SET_LONGJMP_RESUME.  True if we are
> +       handling a longjmp, false if we are handling an exception.  */
> +    int is_longjmp;

This component is also used with BPSTAT_WHAT_CLEAR_LONGJMP_RESUME.

Sorry for not being of any real help in this case...

-- 
Joel


  reply	other threads:[~2010-11-24 17:53 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-07  1:37 Tom Tromey
2010-11-24 17:53 ` Joel Brobecker [this message]
2010-11-24 18:24   ` Tom Tromey
2010-11-25  7:59 ` Jan Kratochvil
2010-11-27 17:25   ` Doug Evans
2010-11-28  8:29     ` Joel Brobecker
2010-11-30 16:43   ` Tom Tromey
2010-11-30 17:02     ` Jan Kratochvil
2010-11-30 17:15       ` Phil Muldoon
2010-11-30 20:15     ` Tom Tromey
2010-12-01 13:42       ` Jan Kratochvil
2010-12-01 21:40     ` Tom Tromey
2010-11-30 18:23   ` Tom Tromey
2010-11-30 18:55     ` Tom Tromey
2010-12-02 15:32 ` Tom Tromey
2010-12-09 16:37   ` Tom Tromey
2010-12-10  4:52     ` Jan Kratochvil
2010-12-10 20:07       ` Tom Tromey
2010-12-11  5:27         ` Jan Kratochvil
2010-12-15 21:18           ` Tom Tromey
  -- strict thread matches above, loose matches on Subject: below --
2009-05-29 22:32 Tom Tromey
2009-05-30 21:08 ` Doug Evans
2009-05-30 23:18   ` Tom Tromey
2009-06-10 16:13 ` Joel Brobecker
2009-06-10 16:50   ` Tom Tromey
2009-06-10 17:05     ` Pedro Alves
2009-06-10 17:13       ` Daniel Jacobowitz
2009-06-10 17:47         ` Pedro Alves
2009-06-10 18:32           ` Tom Tromey
2009-06-10 18:49             ` Pedro Alves
2009-06-12 20:49           ` Tom Tromey
2009-06-12 21:51             ` Pedro Alves
2009-06-12 22:07               ` Pedro Alves
2010-11-25  4:54         ` Jan Kratochvil
2009-06-11 14:45     ` Joel Brobecker
2009-06-11 15:47       ` Tom Tromey
2009-07-24 17:38 ` Tom Tromey
2009-07-24 18:54   ` Pedro Alves
2009-07-24 19:18     ` Tom Tromey
2009-09-09 18:56     ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101124175316.GA2634@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox