[01/10] Standardize darwin's lm_info

Message ID 20170426224706.27988-2-simon.marchi@ericsson.com
State New, archived
Headers

Commit Message

Simon Marchi April 26, 2017, 10:46 p.m. UTC
  From: Simon Marchi <simon.marchi@polymtl.ca>

Darwin's lm_info structure is used a little bit differently than the
other solib implementations.  The other implementations first allocate
an so_list object, then instanciate their specific lm_info structure,
and assign it to so_list::lm_info.

The Darwin implementation allocates both at the same time
(darwin_so_list).  This patch changes it to be like the others, so that
we'll be able to do some generalizations later.

gdb/ChangeLog:

	* solib-darwin.c (struct darwin_so_list): Remove.
	(darwin_current_sos): Allocate an so_list object instead of a
	darwin_so_list, separately allocate an lm_info object.
	(darwin_free_so): Free lm_info.
---
 gdb/solib-darwin.c | 17 ++++-------------
 1 file changed, 4 insertions(+), 13 deletions(-)
  

Comments

Pedro Alves April 28, 2017, 3:57 p.m. UTC | #1
On 04/26/2017 11:46 PM, Simon Marchi wrote:
> From: Simon Marchi <simon.marchi@polymtl.ca>
> 
> Darwin's lm_info structure is used a little bit differently than the
> other solib implementations.  The other implementations first allocate
> an so_list object, then instanciate their specific lm_info structure,
> and assign it to so_list::lm_info.
> 
> The Darwin implementation allocates both at the same time
> (darwin_so_list).  This patch changes it to be like the others, so that
> we'll be able to do some generalizations later.

Funny, so this port was already "inheriting" from so_list.

LGTM.

Thanks,
Pedro Alves
  
Simon Marchi April 28, 2017, 7:32 p.m. UTC | #2
On 2017-04-28 11:57, Pedro Alves wrote:
> On 04/26/2017 11:46 PM, Simon Marchi wrote:
>> From: Simon Marchi <simon.marchi@polymtl.ca>
>> 
>> Darwin's lm_info structure is used a little bit differently than the
>> other solib implementations.  The other implementations first allocate
>> an so_list object, then instanciate their specific lm_info structure,
>> and assign it to so_list::lm_info.
>> 
>> The Darwin implementation allocates both at the same time
>> (darwin_so_list).  This patch changes it to be like the others, so 
>> that
>> we'll be able to do some generalizations later.
> 
> Funny, so this port was already "inheriting" from so_list.

Indeed.  But I thought it would be better as a first step to make all of 
them work in a similar way.  If we proceed with inheriting from so_list, 
we'll do them all at once

> LGTM.
> 
> Thanks,
> Pedro Alves
  

Patch

diff --git a/gdb/solib-darwin.c b/gdb/solib-darwin.c
index 0b975569e2..c507e13caf 100644
--- a/gdb/solib-darwin.c
+++ b/gdb/solib-darwin.c
@@ -159,14 +159,6 @@  struct lm_info
   CORE_ADDR lm_addr;
 };
 
-struct darwin_so_list
-{
-  /* Common field.  */
-  struct so_list sl;
-  /* Darwin specific data.  */
-  struct lm_info li;
-};
-
 /* Lookup the value for a specific symbol.  */
 
 static CORE_ADDR
@@ -271,7 +263,6 @@  darwin_current_sos (void)
       unsigned long hdr_val;
       char *file_path;
       int errcode;
-      struct darwin_so_list *dnew;
       struct so_list *newobj;
       struct cleanup *old_chain;
 
@@ -302,11 +293,10 @@  darwin_current_sos (void)
 	break;
 
       /* Create and fill the new so_list element.  */
-      dnew = XCNEW (struct darwin_so_list);
-      newobj = &dnew->sl;
-      old_chain = make_cleanup (xfree, dnew);
+      newobj = XCNEW (struct so_list);
+      old_chain = make_cleanup (xfree, newobj);
 
-      newobj->lm_info = &dnew->li;
+      newobj->lm_info = XCNEW (struct lm_info);
 
       strncpy (newobj->so_name, file_path, SO_NAME_MAX_PATH_SIZE - 1);
       newobj->so_name[SO_NAME_MAX_PATH_SIZE - 1] = '\0';
@@ -587,6 +577,7 @@  darwin_clear_solib (void)
 static void
 darwin_free_so (struct so_list *so)
 {
+  xfree (so->lm_info);
 }
 
 /* The section table is built from bfd sections using bfd VMAs.