public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] Eliminate target_ops::to_xclose
@ 2018-04-13 17:57 Pedro Alves
  2018-04-27 15:24 ` Tom Tromey
  0 siblings, 1 reply; 3+ messages in thread
From: Pedro Alves @ 2018-04-13 17:57 UTC (permalink / raw)
  To: gdb-patches

In the multi-target branch, I found no need for the target_close vs
target_xclose distinction.  Heap-allocated targets simply delete
themselves in their target_close implementation, while
singleton/static targets don't.

The target_ops C++ification patches will add more commentary around
target_ops's destructor, but there's no destructor yet...

gdb/ChangeLog:
yyyy-mm-dd  Pedro Alves  <palves@redhat.com>

	* bfd-target.c (target_bfd_xclose): Rename to ...
	(target_bfd_close): ... this.
	(target_bfd_reopen): Adjust.
	* target.c (target_close): Remove references to to_xclose.
	* target.h (target_ops::to_xclose): Delete.
	(target_ops::to_close): Update comments.
---
 gdb/bfd-target.c | 4 ++--
 gdb/target.c     | 4 +---
 gdb/target.h     | 9 +++++----
 3 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/gdb/bfd-target.c b/gdb/bfd-target.c
index f7928ee0b9..99b49aad13 100644
--- a/gdb/bfd-target.c
+++ b/gdb/bfd-target.c
@@ -68,7 +68,7 @@ target_bfd_get_section_table (struct target_ops *ops)
 }
 
 static void
-target_bfd_xclose (struct target_ops *t)
+target_bfd_close (struct target_ops *t)
 {
   struct target_bfd_data *data = (struct target_bfd_data *) t->to_data;
 
@@ -95,7 +95,7 @@ target_bfd_reopen (struct bfd *abfd)
   t->to_doc = _("You should never see this");
   t->to_get_section_table = target_bfd_get_section_table;
   t->to_xfer_partial = target_bfd_xfer_partial;
-  t->to_xclose = target_bfd_xclose;
+  t->to_close = target_bfd_close;
   t->to_data = data;
   t->to_magic = OPS_MAGIC;
 
diff --git a/gdb/target.c b/gdb/target.c
index e8d4ae7ea8..2ff028cfa8 100644
--- a/gdb/target.c
+++ b/gdb/target.c
@@ -3416,9 +3416,7 @@ target_close (struct target_ops *targ)
 
   fileio_handles_invalidate_target (targ);
 
-  if (targ->to_xclose != NULL)
-    targ->to_xclose (targ);
-  else if (targ->to_close != NULL)
+  if (targ->to_close != NULL)
     targ->to_close (targ);
 
   if (targetdebug)
diff --git a/gdb/target.h b/gdb/target.h
index f208b10767..f329362285 100644
--- a/gdb/target.h
+++ b/gdb/target.h
@@ -418,11 +418,12 @@ struct target_ops
        stack.  Targets should supply this routine, if only to provide
        an error message.  */
     void (*to_open) (const char *, int);
-    /* Old targets with a static target vector provide "to_close".
-       New re-entrant targets provide "to_xclose" and that is expected
-       to xfree everything (including the "struct target_ops").  */
-    void (*to_xclose) (struct target_ops *targ);
+
+    /* Close the target.  This is where the target can handle
+       teardown.  Heap-allocated targets should delete themselves
+       before returning.  */
     void (*to_close) (struct target_ops *);
+
     /* Attaches to a process on the target side.  Arguments are as
        passed to the `attach' command by the user.  This routine can
        be called when the target is not on the target-stack, if the
-- 
2.14.3

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] Eliminate target_ops::to_xclose
  2018-04-13 17:57 [PATCH] Eliminate target_ops::to_xclose Pedro Alves
@ 2018-04-27 15:24 ` Tom Tromey
  2018-05-03  0:00   ` Pedro Alves
  0 siblings, 1 reply; 3+ messages in thread
From: Tom Tromey @ 2018-04-27 15:24 UTC (permalink / raw)
  To: Pedro Alves; +Cc: gdb-patches

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> In the multi-target branch, I found no need for the target_close vs
Pedro> target_xclose distinction.  Heap-allocated targets simply delete
Pedro> themselves in their target_close implementation, while
Pedro> singleton/static targets don't.

Pedro> The target_ops C++ification patches will add more commentary around
Pedro> target_ops's destructor, but there's no destructor yet...

This looks good to me and it seems like the close/xclose distinction
already doesn't really make sense anyway.

Tom

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] Eliminate target_ops::to_xclose
  2018-04-27 15:24 ` Tom Tromey
@ 2018-05-03  0:00   ` Pedro Alves
  0 siblings, 0 replies; 3+ messages in thread
From: Pedro Alves @ 2018-05-03  0:00 UTC (permalink / raw)
  To: Tom Tromey; +Cc: gdb-patches

On 04/27/2018 04:24 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
> 
> Pedro> In the multi-target branch, I found no need for the target_close vs
> Pedro> target_xclose distinction.  Heap-allocated targets simply delete
> Pedro> themselves in their target_close implementation, while
> Pedro> singleton/static targets don't.
> 
> Pedro> The target_ops C++ification patches will add more commentary around
> Pedro> target_ops's destructor, but there's no destructor yet...
> 
> This looks good to me and it seems like the close/xclose distinction
> already doesn't really make sense anyway.
Thanks for taking a look Tom.  I've merged it.

Thanks,
Pedro Alves

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-05-03  0:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-13 17:57 [PATCH] Eliminate target_ops::to_xclose Pedro Alves
2018-04-27 15:24 ` Tom Tromey
2018-05-03  0:00   ` Pedro Alves

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).