Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Pedro Alves <palves@redhat.com>
Cc: Simon Marchi <simon.marchi@ericsson.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Make breakpoint subclasses inherit from breakpoint, add  virtual destructor
Date: Wed, 03 May 2017 14:36:00 -0000	[thread overview]
Message-ID: <647998f3cb9e763dd7da94e9c9d675ca@polymtl.ca> (raw)
In-Reply-To: <0f7aaf0f-6498-2b2e-7cc9-e7656fbc6079@redhat.com>

On 2017-05-03 06:17, Pedro Alves wrote:
> Hi Simon,
> 
> Many thanks for doing this.
> 
> On 05/02/2017 08:18 PM, Simon Marchi wrote:
>> From: Simon Marchi <simon.marchi@polymtl.ca>
>> 
>> Tom recently mentioned on IRC how breakpoint deallocation looked 
>> fishy.  A
>> syscall catchpoint, for example, is created with "new 
>> syscall_catchpoint", but
>> free'd using "delete bpt", where bpt is a breakpoint *.
> 
> Note that currently the the "syscall_catchpoint"
> part is freed by dtor_catch_syscall, called via the 
> breakpoint_ops->dtor.

Right.

>   bpt->ops->dtor (bpt); <<< here
>   /* On the chance that someone will soon try again to delete this
>      same bp, we mark it as deleted before freeing its storage.  */
>   bpt->type = bp_none;
>   delete bpt;
> 
> But of course, that only works as long as "syscall_catchpoint"'s fields
> are trivially destructible.  Otherwise the breakpoint_ops->dtor method
> would have to call desctructors manually.  Urgh.

Right.

>> I had this patch lying
>> around in a branch, so I decided to post it by itself.
> 
>> 
>> I want to replace the vectors in the various breakpoint subclasses by
>> std::vector.  The problem right now is that while breakpoint
>> subclasses are constructed using new, they are not properly deleted.
> 
> I think "properly deleted" might not be 100% accurate.

Hmm what do you suggest?  I could say:

   ... their C++ destructor is not being called.

>> The only place breakpoints are deleted is through a breakpoint pointer
>> in delete_breakpoint.  This means that even if I add a destructor in a
>> subclass (e.g. syscall_catchpoint), it's not going to be called, for 
>> two
>> reasons:
>> 
>> 1. The destructor of breakpoint needs to be virtual if we want the
>>    destructors from the subclasses to be called.
>> 2. The subclasses need to be actual subclasses, not just include the
>>    base class as a field.
>> 
>> It turns out at #2 generates a lot of small changes (removing "base."
>> everywhere), but it makes the code generally a bit nicer.
> 
> Most of the breakpoint_ops function pointers should really be virtual 
> methods
> of struct breakpoint.  Over the years, they've been adjusted to map 
> better
> to a vtable model [1], though there are a few that are really factory
> methods that don't translate properly, because they would require a 
> breakpoint
> instance to be called on, when their purpose is to create said 
> instances.
> "breakpoint_ops::dtor" is really the most obvious one and best one
> to kickstart such a conversion.

Indeed.

> [1] e.g. https://sourceware.org/ml/gdb-patches/2011-06/msg00269.html,
> https://sourceware.org/ml/gdb-patches/2011-06/msg00296.html.
> 
> But I'm then surprised that the patch doesn't eliminate 
> breakpoint_ops::dtor
> at the same time.  The patch would be simple to justify in those terms
> (breakpoint_ops::dtor -> real breakpoint C++ dtor).  If 
> breakpoint_ops::dtor
> is still necessary, then this patch is probably not complete?  If we 
> keep
> it, then destruction still looks fishy to me, with the C++ dtor 
> potentially
> destroying objects that breakpoint_ops::dtor already freed.  Could you 
> take
> a look at that, see if it doesn't cause this patch to grow too much?  I 
> think
> not, I think mostly you'll just need to rename a few dtor_foo methods
> to foo::~foo.

You're right, it would be confusing and ugly to leave it with a 
half-baked-dual-hybrid system with C++ destructors and dtor ops.  I'll 
remove the dtor op, it shouldn't be much work, as you said.

>> 
>> gdb/ChangeLog:
>> 
>> 	* ada-lang.c (struct ada_catchpoint): Inherit from struct
>> 	breakpoint.
>> 	<base>: Remove.
>> 	(create_excep_cond_exprs): Adjust.
>> 	(create_ada_exception_catchpoint): Adjust.
>> 	* break-catch-sig.c (struct signal_catchpoint): Inherit from
>> 	struct breakpoint.
>> 	<base>: Remove.
>> 	(create_signal_catchpoint): Adjust.
>> 	* break-catch-syscall.c (UNKNOWN): Adjust.
>> 	(create_syscall_event_catchpoint): Adjust.
>> 	* break-catch-throw.c (static): Adjust.
>> 	(handle_gnu_v3_exceptions): Adjust.
>> 	* breakpoint.c (is_watchpoint): Adjust.
>> 	(watchpoint_in_thread_scope): Adjust.
>> 	(update_watchpoint): Adjust.
>> 	(watchpoint_check): Adjust.
>> 	(bpstat_check_watchpoint): Adjust.
>> 	(disable_breakpoints_in_freed_objfile): Adjust.
>> 	(print_recreate_catch_vfork): Adjust.
>> 	(breakpoint_hit_catch_solib): Adjust.
>> 	(add_solib_catchpoint): Adjust.
>> 	(create_fork_vfork_event_catchpoint): Adjust.
>> 	(create_breakpoint_sal): Adjust.
>> 	(create_breakpoint): Adjust.
> 
>> 	(static): Adjust.
> 
> This entry doesn't look right.

Oops, so this ChangeLog looked done when I cherry-picked the patch from 
the branch, but clearly it was still raw (those are artifacts from the 
generate-changelog.py script).  I'll put it back in the oven.

Thanks,

Simon


  reply	other threads:[~2017-05-03 14:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-02 19:19 Simon Marchi
2017-05-03 10:17 ` Pedro Alves
2017-05-03 14:36   ` Simon Marchi [this message]
2017-05-03 15:08     ` Pedro Alves
2017-05-03 15:23       ` Simon Marchi
2017-05-03 15:27         ` Pedro Alves

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=647998f3cb9e763dd7da94e9c9d675ca@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=simon.marchi@ericsson.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