Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* PATCH: relax restrictions on per-architecture data registration
       [not found] <20010601233233.C19845E9CB@zwingli.cygnus.com>
@ 2001-06-01 20:54 ` Jim Blandy
  2001-06-06  4:59 ` RFA: " Andrew Cagney
  2001-06-06  6:34 ` Andrew Cagney
  2 siblings, 0 replies; 7+ messages in thread
From: Jim Blandy @ 2001-06-01 20:54 UTC (permalink / raw)
  To: gdb-patches

I tested this on a multi-arch target, and it seemed to work, so I've
committed it.

Jim Blandy <jimb@cygnus.com> writes:
> This is supposed to fix G++ V3 on non-multiarch targets.  Not sure
> this is right yet, just posting for the curious.
> 
> 2001-06-01  Jim Blandy  <jimb@redhat.com>
> 
> 	Expand the gdbarch per-architecture data vector as needed, rather
> 	than requiring that all per-architecture data be registered before
> 	the first gdbarch object is allocated.
> 	* gdbarch.sh: Changes to effect the following:
> 	* gdbarch.c (alloc_gdbarch_data, init_gdbarch_data): Delete
> 	declarations and definitions.
> 	(check_gdbarch_data): New function, and declaration.
> 	(gdbarch_alloc): Don't call alloc_gdbarch_data; leaving the fields
> 	zero is good enough.
> 	(free_gdbarch_data): Tolerate a null data pointer.  Free only
> 	those data items gdbarch->data actually has allocated.
> 	(set_gdbarch_data, gdbarch_data): Call check_gdbarch_data.
> 	(gdbarch_update_p): No need to call init_gdbarch_data.


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

* Re: RFA: relax restrictions on per-architecture data registration
       [not found] <20010601233233.C19845E9CB@zwingli.cygnus.com>
  2001-06-01 20:54 ` PATCH: relax restrictions on per-architecture data registration Jim Blandy
@ 2001-06-06  4:59 ` Andrew Cagney
  2001-06-06  7:39   ` Jim Blandy
  2001-06-06  6:34 ` Andrew Cagney
  2 siblings, 1 reply; 7+ messages in thread
From: Andrew Cagney @ 2001-06-06  4:59 UTC (permalink / raw)
  To: Jim Blandy; +Cc: gdb-patches

> This is supposed to fix G++ V3 on non-multiarch targets.  Not sure
> this is right yet, just posting for the curious.
> 
> 2001-06-01  Jim Blandy  <jimb@redhat.com>
> 
> Expand the gdbarch per-architecture data vector as needed, rather
> 	than requiring that all per-architecture data be registered before
> 	the first gdbarch object is allocated.
> 	* gdbarch.sh: Changes to effect the following:
> 	* gdbarch.c (alloc_gdbarch_data, init_gdbarch_data): Delete
> 	declarations and definitions.
> 	(check_gdbarch_data): New function, and declaration.
> 	(gdbarch_alloc): Don't call alloc_gdbarch_data; leaving the fields
> 	zero is good enough.
> 	(free_gdbarch_data): Tolerate a null data pointer.  Free only
> 	those data items gdbarch->data actually has allocated.
> 	(set_gdbarch_data, gdbarch_data): Call check_gdbarch_data.
> 	(gdbarch_update_p): No need to call init_gdbarch_data.
> 
> 

Jim,

I think this is wrong.  GDB's startup sequence is currently something like:

	o	_initialize_*() registers any
		per-architecture data

	o	GDB creates the initial architecture

So that data buffer size would never change.

	Andrew

PS: xmalloc(size) == zrealloc (NULL, size)






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

* Re: RFA: relax restrictions on per-architecture data registration
       [not found] <20010601233233.C19845E9CB@zwingli.cygnus.com>
  2001-06-01 20:54 ` PATCH: relax restrictions on per-architecture data registration Jim Blandy
  2001-06-06  4:59 ` RFA: " Andrew Cagney
@ 2001-06-06  6:34 ` Andrew Cagney
  2001-06-06  9:59   ` RFA: initialize per-arch data in startup_gdbarch Jim Blandy
  2 siblings, 1 reply; 7+ messages in thread
From: Andrew Cagney @ 2001-06-06  6:34 UTC (permalink / raw)
  To: Jim Blandy; +Cc: gdb-patches

Jim,

To follow up my previous post.  All I think is needed is for the code in 
arch-utils.c:initialize_current_architecture():


   if (GDB_MULTI_ARCH)
     {
       if (! gdbarch_update_p (info))
         {
           internal_error (__FILE__, __LINE__,
                           "initialize_current_architecture: Selection 
of initial architecture
failed");
         }
     }

to be tweeked so that, when there is no multi-arch, the data vector is 
still initialized.

	Andrew


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

* Re: RFA: relax restrictions on per-architecture data registration
  2001-06-06  4:59 ` RFA: " Andrew Cagney
@ 2001-06-06  7:39   ` Jim Blandy
  2001-06-06  9:35     ` Andrew Cagney
  0 siblings, 1 reply; 7+ messages in thread
From: Jim Blandy @ 2001-06-06  7:39 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: gdb-patches

Andrew Cagney <ac131313@cygnus.com> writes:
> > 2001-06-01  Jim Blandy  <jimb@redhat.com>
> > 
> > Expand the gdbarch per-architecture data vector as needed, rather
> > 	than requiring that all per-architecture data be registered before
> > 	the first gdbarch object is allocated.
> > 	* gdbarch.sh: Changes to effect the following:
> > 	* gdbarch.c (alloc_gdbarch_data, init_gdbarch_data): Delete
> > 	declarations and definitions.
> > 	(check_gdbarch_data): New function, and declaration.
> > 	(gdbarch_alloc): Don't call alloc_gdbarch_data; leaving the fields
> > 	zero is good enough.
> > 	(free_gdbarch_data): Tolerate a null data pointer.  Free only
> > 	those data items gdbarch->data actually has allocated.
> > 	(set_gdbarch_data, gdbarch_data): Call check_gdbarch_data.
> > 	(gdbarch_update_p): No need to call init_gdbarch_data.
> 
> I think this is wrong.  GDB's startup sequence is currently something like:
> 
> 	o	_initialize_*() registers any
> 		per-architecture data
> 
> 	o	GDB creates the initial architecture
> 
> So that data buffer size would never change.
> 
> To follow up my previous post.  All I think is needed is for the code in 
> arch-utils.c:initialize_current_architecture():
> 
> 
>    if (GDB_MULTI_ARCH)
>      {
>        if (! gdbarch_update_p (info))
>          {
>            internal_error (__FILE__, __LINE__,
>                            "initialize_current_architecture: Selection 
> of initial architecture
> failed");
>          }
>      }
> 
> to be tweeked so that, when there is no multi-arch, the data vector is 
> still initialized.

Okay.  My first patch was exactly that, but then I felt like I was
assuming that all per-architecture data would be registered by the
time initialization was done, which wasn't a documented requirement in
gdbarch.h.  So I made it more dynamic.

I'll revert my patch, and post a new one shortly.


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

* Re: RFA: relax restrictions on per-architecture data registration
  2001-06-06  7:39   ` Jim Blandy
@ 2001-06-06  9:35     ` Andrew Cagney
  0 siblings, 0 replies; 7+ messages in thread
From: Andrew Cagney @ 2001-06-06  9:35 UTC (permalink / raw)
  To: Jim Blandy; +Cc: gdb-patches

> Okay.  My first patch was exactly that, but then I felt like I was
> assuming that all per-architecture data would be registered by the
> time initialization was done, which wasn't a documented requirement in
> gdbarch.h.  So I made it more dynamic.


Ah.

My e-mail actually contained a white lie.  At present it really does:

	o	compile in a static dummy architecture and
		wire things to use that

	o	call _initialize_*()

	o	create the real architecture

the first step, a hack, is to get around a chicken/egg problem with the 
current GDB code.  gdbtypes.[hc] assumes that there is an architecture 
_before_ anything has been initialized (ulgh).

As usual, the long term objective is to eliminate the hack :-)  Tweeking 
the ``create the real architecture'' code to create the data vector in 
both the multi-arch and non-multi-arch cases will actually take this a 
step closer - chunks of GDB can be rewritten to just use the 
register_gdbarch_data() mechanism.

I'll add a comment to top.c / gdbint.texinfo to explain this.

	Andrew


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

* Re: RFA: initialize per-arch data in startup_gdbarch
  2001-06-06  6:34 ` Andrew Cagney
@ 2001-06-06  9:59   ` Jim Blandy
  2001-06-06 10:13     ` Andrew Cagney
  0 siblings, 1 reply; 7+ messages in thread
From: Jim Blandy @ 2001-06-06  9:59 UTC (permalink / raw)
  To: gdb-patches; +Cc: Andrew Cagney

Here's the (much simpler) patch that works the way you want, I think.

2001-06-06  Jim Blandy  <jimb@redhat.com>

	* gdbarch.sh: Changes to effect the following:
	* gdbarch.c (initialize_non_multiarch): New function.
	* gdbarch.h (initialize_non_multiarch): New declaration.
	* arch-utils.c (initialize_current_architecture): For
	non-multiarch configurations, call initialize_non_multiarch.

Index: gdb/arch-utils.c
===================================================================
RCS file: /cvs/src/src/gdb/arch-utils.c,v
retrieving revision 1.27
diff -c -r1.27 arch-utils.c
*** gdb/arch-utils.c	2001/05/10 18:36:26	1.27
--- gdb/arch-utils.c	2001/06/06 16:55:00
***************
*** 701,706 ****
--- 701,708 ----
  			  "initialize_current_architecture: Selection of initial architecture failed");
  	}
      }
+   else
+     initialize_non_multiarch ();
  
    /* Create the ``set architecture'' command appending ``auto'' to the
       list of architectures. */
Index: gdb/gdbarch.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.c,v
retrieving revision 1.61
diff -c -r1.61 gdbarch.c
*** gdb/gdbarch.c	2001/06/06 14:46:30	1.61
--- gdb/gdbarch.c	2001/06/06 16:55:03
***************
*** 387,392 ****
--- 387,401 ----
  
  struct gdbarch *current_gdbarch = &startup_gdbarch;
  
+ /* Do any initialization needed for a non-multiarch configuration
+    after the _initialize_MODULE functions have been run.  */
+ void
+ initialize_non_multiarch ()
+ {
+   alloc_gdbarch_data (&startup_gdbarch);
+   init_gdbarch_data (&startup_gdbarch);
+ }
+ 
  
  /* Create a new ``struct gdbarch'' based on information provided by
     ``struct gdbarch_info''. */
Index: gdb/gdbarch.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.h,v
retrieving revision 1.49
diff -c -r1.49 gdbarch.h
*** gdb/gdbarch.h	2001/05/14 16:43:35	1.49
--- gdb/gdbarch.h	2001/06/06 16:55:04
***************
*** 1834,1839 ****
--- 1834,1843 ----
  
  extern void initialize_current_architecture (void);
  
+ /* For non-multiarched targets, do any initialization of the default
+    gdbarch object necessary after the _initialize_MODULE functions
+    have run.  */
+ extern void initialize_non_multiarch ();
  
  /* gdbarch trace variable */
  extern int gdbarch_debug;
Index: gdb/gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.64
diff -c -r1.64 gdbarch.sh
*** gdb/gdbarch.sh	2001/06/06 14:46:30	1.64
--- gdb/gdbarch.sh	2001/06/06 16:55:05
***************
*** 1065,1070 ****
--- 1065,1074 ----
  
  extern void initialize_current_architecture (void);
  
+ /* For non-multiarched targets, do any initialization of the default
+    gdbarch object necessary after the _initialize_MODULE functions
+    have run.  */
+ extern void initialize_non_multiarch ();
  
  /* gdbarch trace variable */
  extern int gdbarch_debug;
***************
*** 1246,1251 ****
--- 1250,1264 ----
  };
  
  struct gdbarch *current_gdbarch = &startup_gdbarch;
+ 
+ /* Do any initialization needed for a non-multiarch configuration
+    after the _initialize_MODULE functions have been run.  */
+ void
+ initialize_non_multiarch ()
+ {
+   alloc_gdbarch_data (&startup_gdbarch);
+   init_gdbarch_data (&startup_gdbarch);
+ }
  EOF
  
  # Create a new gdbarch struct


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

* Re: RFA: initialize per-arch data in startup_gdbarch
  2001-06-06  9:59   ` RFA: initialize per-arch data in startup_gdbarch Jim Blandy
@ 2001-06-06 10:13     ` Andrew Cagney
  0 siblings, 0 replies; 7+ messages in thread
From: Andrew Cagney @ 2001-06-06 10:13 UTC (permalink / raw)
  To: Jim Blandy; +Cc: gdb-patches

> 2001-06-06  Jim Blandy  <jimb@redhat.com>
> 
> * gdbarch.sh: Changes to effect the following:
> 	* gdbarch.c (initialize_non_multiarch): New function.
> 	* gdbarch.h (initialize_non_multiarch): New declaration.
> 	* arch-utils.c (initialize_current_architecture): For
> 	non-multiarch configurations, call initialize_non_multiarch.
> 
> 

Yes, thanks!
	Andrew



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

end of thread, other threads:[~2001-06-06 10:13 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20010601233233.C19845E9CB@zwingli.cygnus.com>
2001-06-01 20:54 ` PATCH: relax restrictions on per-architecture data registration Jim Blandy
2001-06-06  4:59 ` RFA: " Andrew Cagney
2001-06-06  7:39   ` Jim Blandy
2001-06-06  9:35     ` Andrew Cagney
2001-06-06  6:34 ` Andrew Cagney
2001-06-06  9:59   ` RFA: initialize per-arch data in startup_gdbarch Jim Blandy
2001-06-06 10:13     ` Andrew Cagney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox