Toolchain/binutils-gdb
1
0
Fork 0
forked from Imagelibrary/binutils-gdb
Code Pull Requests Activity

Eliminate target_ops::to_xclose

Browse Source 
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:
2018-05-02  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.
This commit is contained in:
Pedro Alves
2018-05-03 00:37:09 +01:00
parent 6798487f5b
commit 3fffc0701a
4 changed files with 17 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
gdb/target.h
View File

@@ -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