Re: Minor fix to comment in "minsyms.c"

[Jim Blandy <jimb@zwingli.cygnus.com>]

Thanks, I've committed this.

> "I see no MSYMBOL_HASH_ADD here."  One version of the minsyms hashing
> patch had that macro, but the code in the CVS tree has the
> "add_minsym_to_hash_table()" function instead.
> 
> *** /u/guy/src/cmd/gdb-cygnus-cvs/gdb/minsyms.c	Tue Apr 18 17:35:37 2000
> --- ./minsyms.c	Tue Apr 18 17:55:52 2000
> ***************
> *** 685,691 ****
>     MSYMBOL_INFO (msymbol) = info;	/* FIXME! */
>   
>     /* The hash pointers must be cleared! If they're not,
> !      MSYMBOL_HASH_ADD will NOT add this msymbol to the hash table. */
>     msymbol->hash_next = NULL;
>     msymbol->demangled_hash_next = NULL;
>   
> --- 685,691 ----
>     MSYMBOL_INFO (msymbol) = info;	/* FIXME! */
>   
>     /* The hash pointers must be cleared! If they're not,
> !      add_minsym_to_hash_table will NOT add this msymbol to the hash table. */
>     msymbol->hash_next = NULL;
>     msymbol->demangled_hash_next = NULL;
>   
> 
From jimb@zwingli.cygnus.com Wed Apr 19 14:20:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Jim Blandy <jimb@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: gdbarchify RETURN_VALUE_ON_STACK
Date: Wed, 19 Apr 2000 14:20:00 -0000
Message-id: <npbt35pz49.fsf@zwingli.cygnus.com>
References: <200004182327.SAA10393@zwingli.cygnus.com> <38FD0067.82067D1E@cygnus.com>
X-SW-Source: 2000-04/msg00382.html
Content-length: 1126

> > 2000-04-17  Jim Blandy  <jimb@redhat.com>
> > 
> >         Bring RETURN_VALUE_ON_STACK under gdbarch's control.
> >         * gdbarch.sh (RETURN_VALUE_ON_STACK): New entry.
> >         * gdbarch.c, gdbarch.h: Regenerated.
> >         * arch-utils.c (default_return_value_on_stack): New function.
> >         * arch-utils.h (default_return_value_on_stack): New declaration.
> 
> I'd suggest the function name ``generic_return_value_on_stack_not'' (I
> know the name grates) declared as:
> extern gdbarch_return_value_on_stack_ftype ...;
> 
> For the arch line, I'd suggest the change:
> 
> - f:2:RETURN_VALUE_ON_STACK:int:return_value_on_stack:struct type
> *type:type:::default_return_value_on_stack
> + f:2:RETURN_VALUE_ON_STACK:int:return_value_on_stack:struct type
> *type:type:::default_return_value_on_stack:0
> 
> (I think I've set valid_p=0).  The generated gdbarch.[hc] will then
> always provide a default.  That in turn allowing the #ifndef
> RETURN_VALUE_ON_STACK in values.c to be deleted.  Have a look at
> REGISTER_NAME.
> 
> After that its ok,

Okay --- I've made these changes, and will commit the result.
From ac131313@cygnus.com Wed Apr 19 16:07:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Alexandre Oliva <aoliva@cygnus.com>
Cc: Jim Blandy <jimb@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: gdbarch IEEE_FLOAT
Date: Wed, 19 Apr 2000 16:07:00 -0000
Message-id: <38FE3BC3.99920D3C@cygnus.com>
References: <200004110302.WAA13962@zwingli.cygnus.com> <38F41405.8F24928@cygnus.com> <np7le0lcjb.fsf@zwingli.cygnus.com> <orln2atjnx.fsf@zecarneiro.lsd.ic.unicamp.br>
X-SW-Source: 2000-04/msg00383.html
Content-length: 689

Alexandre Oliva wrote:
> 
> On Apr 14, 2000, Jim Blandy <jimb@zwingli.cygnus.com> wrote:
> 
> >> BTW, the need to add the below is going away soon.  I've pending
> >> multi-arch patches that will provide this as a non- multi-arch default.
> >>
> >> > + /* Provide a default value for IEEE_FLOAT.  */
> >> > + #ifndef IEEE_FLOAT
> >> > + #define IEEE_FLOAT (0)
> >> > + #endif
> 
> > Sounds great to me!
> 
> BTW, are you aware that gdbarch.c fails to compile on a single-arch
> build whose target header file doesn't define IEEE_FLOAT?  For
> example, I've configured --target=mn10300-elf, and gdbarch.c won't
> build because IEEE_FLOAT is not defined.

I believe this was fixed.

	Andrew
From ac131313@cygnus.com Wed Apr 19 17:49:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: BINUTILS Patches <binutils@sourceware.cygnus.com>
Cc: Eli Zaretskii <eliz@is.elta.co.il>, gdb-patches@sourceware.cygnus.com
Subject: Re: Problems with snapshot 20000412
Date: Wed, 19 Apr 2000 17:49:00 -0000
Message-id: <38FE53D4.F249A6FA@cygnus.com>
References: <200004160807.EAA10378@indy.delorie.com> <38FD3F8C.B30CA4BF@cygnus.com> <200004190745.DAA14311@indy.delorie.com> <38FD6E92.8B94D0A0@cygnus.com>
X-SW-Source: 2000-04/msg00384.html
Content-length: 1895

[Mailing lists changed, take care]

Hello,

The automake-000227.tar.bz2 snapshot contains the bug fixed by the
patch:

http://sourceware.cygnus.com/cgi-bin/cvsweb.cgi/automake/automake.in.diff?r1=1.652&r2=1.653&cvsroot=automake

The bug causes bfd/doc/Makefile.in to contain bogus lines like:

.texi.dvi:
        TEXINPUTS=$(top_srcdir)/../texinfo/texinfo.tex:$$TEXINPUTS \
          MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) $<

(the ``/texinfo.tex'' shouldn't be there).  This in turn (as Eli notes
:-) leads to a failed (when there is no pre-installed texinfo.tex) or
broken (when there is) build.

Could I suggest an update to the automake snapshot.  Then a fixed
bfd/doc/Makefile.in can be re-generated (gdb-5.0 and binutils-N.NN
branches + trunk).

	enjoy,
		Andrew

Andrew Cagney wrote:
> 
> Eli Zaretskii wrote:
> >
> > > It doesn't appear to affect the build
> >
> > Really?  Did you try renaming your system-wide texinfo.tex (somewhere
> > in the TeX installation tree)?
> 
> Hmm, ok, yes point taken :-)
> 
> > The special setting of TEXINPUTS before invoking TeX-related commands
> > is there to make sure that the manual is produced using the specific
> > version of texinfo.tex that was used by the maintainer(s), because
> > another version of texinfo.tex might produce incorrect results or even
> > fail.  If you have the same or compatible version of texinfo.tex in
> > another place where TeX can find it, you won't see the problems caused
> > by TEXINPUTS being set incorrectly.
> 
> Its already been reported:
> 
> http://sourceware.cygnus.com/ml/bug-automake/1999/msg00007.html
> 
> and the follow up:
> 
> http://sourceware.cygnus.com/ml/bug-automake/1999/msg00019.html
> 
> claims:
> 
> > > TEXINPUTS should be a list of directories.
> >
> > Yup, this has been fixed in the CVS tree for quite some time.
> 
> I'll double check my automake tools.
> 
>         Andrew
From jimb@zwingli.cygnus.com Wed Apr 19 18:34:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: shebs@apple.com, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: Document RETURN_VALUE_ON_STACK
Date: Wed, 19 Apr 2000 18:34:00 -0000
Message-id: <npya69o8rm.fsf@zwingli.cygnus.com>
References: <200004181954.OAA08866@zwingli.cygnus.com> <38FCC3DD.533C7037@apple.com> <npitxfoxew.fsf@zwingli.cygnus.com> <200004190737.DAA14301@indy.delorie.com>
X-SW-Source: 2000-04/msg00385.html
Content-length: 729

> From: Jim Blandy <jimb@zwingli.cygnus.com>
> Date: 18 Apr 2000 17:29:43 -0500
> 
> > + @item RETURN_VALUE_ON_STACK(@var{type})
> 
> I think gdbint.texinfo needs to index all the functions and macros it
> documents.  I know that some victim^H^H^H^H^H^Hvolunteer should go
> through the entire file and add the indexing for what's already there,
> but there should be no reason to make that job larger.
> 
> So could we _please_ start adding such index entries to every new
> function/macro/variable we add to the manual?  I suggest @findex for
> functions and macros and @vindex for variables (if there are any).

I think we should be using @deftypefn for everything; that will build
a function index for us automatically.  No?
From ac131313@cygnus.com Wed Apr 19 21:23:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: gdbarch IEEE_FLOAT
Date: Wed, 19 Apr 2000 21:23:00 -0000
Message-id: <38FE85F2.5472031@cygnus.com>
References: <200004110302.WAA13962@zwingli.cygnus.com> <38F41405.8F24928@cygnus.com> <np7le0lcjb.fsf@zwingli.cygnus.com> <38FA86D1.2E4CB93D@cygnus.com> <npu2gzp7hf.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-04/msg00386.html
Content-length: 818

Jim Blandy wrote:
> 
> > > > > + /* Provide a default value for IEEE_FLOAT.  */
> > > > > + #ifndef IEEE_FLOAT
> > > > > + #define IEEE_FLOAT (0)
> > > > > + #endif
> > >
> > > Sounds great to me!
> >
> > BTW, is the default ``0'' or ``1''?  The above has zero, but for
> > multi-arch it is set to one.  (Just let me know, I'll tweek it when I
> > remove it :-).
> 
> Well, for old targets it has to be zero.
> 
> I was thinking that, for new gdbarch-style targets, 1 was the more
> convenient default, but on more careful reflection, I'm not sure
> that's smart: if someone is converting an existing port to gdbarch, it
> would be very confusing for IEEE_FLOAT to suddenly change its default
> value.
> 
> So the default should be zero.

Everyone multi-arching please note.  I've just committed this change.

	Andrew
From ac131313@cygnus.com Wed Apr 19 21:25:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [RFC] Cleanup (TARGET_BFD_VMA_BIT, IEEE_FLOAT, CALL_DUMMY_WORDS and SIZEOF_CALL_DUMMY_WORDS
Date: Wed, 19 Apr 2000 21:25:00 -0000
Message-id: <38FE8668.719EEF2C@cygnus.com>
References: <38FA8EF2.BC8ACBFD@cygnus.com>
X-SW-Source: 2000-04/msg00387.html
Content-length: 1085

Andrew Cagney wrote:
> 
> Hello,
> 
> The attatched patch does to several multi-arch variables what my
> previous patch did to functions.  It changes gdbarch.h so that it
> provides the default for both the multi-arch and non- multi-arch cases.
> 
> (It isn't final as I need info from JimB)
> 
> I'll look to apply it in a few days once the last patch has settled
> down.
> 
>         Andrew
> 
>   ------------------------------------------------------------------------
> Mon Apr 17 13:37:10 2000  Andrew Cagney  <cagney@b1.cygnus.com>
> 
>         * gdbarch.sh: Make multi-arch variable defaults, defaults for non-
>         multi-arch targets.
>         (TARGET_BFD_VMA_BIT, IEEE_FLOAT, CALL_DUMMY_WORDS,
>         SIZEOF_CALL_DUMMY_WORDS): Update.
> 
>         * inferior.h (CALL_DUMMY_WORDS, SIZEOF_CALL_DUMMY_WORDS): Default
>         provided by gdbarch.
>         (CALL_DUMMY_P): Add FIXME. gdbarch should provide default.
> 
>         * valprint.c (IEEE_FLOAT): Default provided by gdbarch.

I've committed this change to the trunk.  IEEE_FLOAT is zero by default.

	Andrew
From ac131313@cygnus.com Thu Apr 20 01:09:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [RFC] Convert STACK_ALIGN to multi-arch ....
Date: Thu, 20 Apr 2000 01:09:00 -0000
Message-id: <38FEBAE3.D0FD616D@cygnus.com>
X-SW-Source: 2000-04/msg00388.html
Content-length: 9322

Hello,

The attached patch converts the STACK_ALIGN macro into a multi-arch
runtime test/call.  What was:

	#ifdef STACK_ALIGN
		x = STACK_ALIGN (x)
	#endif

becomes

	if (STACK_ALIGN_P ())
	  x = STACK_ALIGN (x);

The need for a predicate becomes clear if you look at valops.c.  How it
handles all the possible compatibility cases is pretty confusing so I'll
quickly go through each case I thought of:

	!multi-arch && !defined (STACK_ALIGN)
		A legacy system that doesn't define STACK_ALIGN.
		STACK_ALIGN_P() is defined as gdbarch_stack_align_p()
		which will always return 0 (the stack_align function is
		never set).
		STACK_ALIGN() is defined as gdbarch_stack_align() which
		keeps things compiling.

	!multi-arch && defined (STACK_ALIGN)
		Legacy system providing STACK_ALIGN macro in tm.h.
	multi-arch && defined (STACK_ALIGN)
		Hybrid system (ex d10v) providing STACK_ALIGN macro in tm.h.
		That legacy #ifdef STACK_ALIGN in gdbarch.h forces
		STACK_ALIGN_P() to 1.

	multi-arch && !defined (STACK_ALIGN)
		normal case.
		Both STACK_ALIGN_P() and STACK_ALIGN() are mapped
		onto functions like any other gdbarch case.

can anyone think of any other cases (did I get these cases right :-)? 
Other thoughts.

	Andrew
Thu Apr 20 14:35:46 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* valops.c (hand_function_call): Replace #ifdef STACK_ALIGN with
 	run-time test for STACK_ALIGN_P.
	* gdbarch.sh: Add support for function and variable predicates.
	(STACK_ALIGN): Add.  Implement with predicate - STACK_ALIGN_P.

Index: gdbarch.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.c,v
retrieving revision 1.14
diff -p -r1.14 gdbarch.c
*** gdbarch.c	2000/04/20 04:24:03	1.14
--- gdbarch.c	2000/04/20 07:49:16
*************** struct gdbarch
*** 213,218 ****
--- 213,219 ----
    gdbarch_frame_locals_address_ftype *frame_locals_address;
    gdbarch_saved_pc_after_call_ftype *saved_pc_after_call;
    gdbarch_frame_num_args_ftype *frame_num_args;
+   gdbarch_stack_align_ftype *stack_align;
  };
  
  
*************** struct gdbarch startup_gdbarch = {
*** 317,322 ****
--- 318,324 ----
    0,
    0,
    0,
+   0,
    /* startup_gdbarch() */
  };
  struct gdbarch *current_gdbarch = &startup_gdbarch;
*************** verify_gdbarch (struct gdbarch *gdbarch)
*** 620,625 ****
--- 622,628 ----
    if ((GDB_MULTI_ARCH >= 2)
        && (gdbarch->frame_num_args == 0))
      internal_error ("gdbarch: verify_gdbarch: frame_num_args invalid");
+   /* Skip verify of stack_align, has predicate */
  }
  
  
*************** gdbarch_dump (void)
*** 955,960 ****
--- 958,967 ----
                        "gdbarch_update: FRAME_NUM_ARGS = 0x%08lx\n",
                        (long) current_gdbarch->frame_num_args
                        /*FRAME_NUM_ARGS ()*/);
+   fprintf_unfiltered (gdb_stdlog,
+                       "gdbarch_update: STACK_ALIGN = 0x%08lx\n",
+                       (long) current_gdbarch->stack_align
+                       /*STACK_ALIGN ()*/);
  }
  
  struct gdbarch_tdep *
*************** set_gdbarch_frame_num_args (struct gdbar
*** 2485,2490 ****
--- 2492,2520 ----
                              gdbarch_frame_num_args_ftype frame_num_args)
  {
    gdbarch->frame_num_args = frame_num_args;
+ }
+ 
+ int
+ gdbarch_stack_align_p (struct gdbarch *gdbarch)
+ {
+   return gdbarch->stack_align != 0;
+ }
+ 
+ CORE_ADDR
+ gdbarch_stack_align (struct gdbarch *gdbarch, CORE_ADDR sp)
+ {
+   if (gdbarch->stack_align == 0)
+     internal_error ("gdbarch: gdbarch_stack_align invalid");
+   if (gdbarch_debug >= 2)
+     fprintf_unfiltered (gdb_stdlog, "gdbarch_stack_align called\n");
+   return gdbarch->stack_align (sp);
+ }
+ 
+ void
+ set_gdbarch_stack_align (struct gdbarch *gdbarch,
+                          gdbarch_stack_align_ftype stack_align)
+ {
+   gdbarch->stack_align = stack_align;
  }
  
  
Index: gdbarch.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.h,v
retrieving revision 1.10
diff -p -r1.10 gdbarch.h
*** gdbarch.h	2000/04/20 04:24:04	1.10
--- gdbarch.h	2000/04/20 07:49:19
*************** extern void set_gdbarch_frame_num_args (
*** 798,803 ****
--- 798,820 ----
  #endif
  #endif
  
+ #if defined (STACK_ALIGN)
+ /* Legacy for systems yet to multi-arch STACK_ALIGN */
+ #define STACK_ALIGN_P() (1)
+ #endif
+ 
+ extern int gdbarch_stack_align_p (struct gdbarch *gdbarch);
+ #if (GDB_MULTI_ARCH > 1) || !defined (STACK_ALIGN_P)
+ #define STACK_ALIGN_P() (gdbarch_stack_align_p (current_gdbarch))
+ #endif
+ 
+ typedef CORE_ADDR (gdbarch_stack_align_ftype) (CORE_ADDR sp);
+ extern CORE_ADDR gdbarch_stack_align (struct gdbarch *gdbarch, CORE_ADDR sp);
+ extern void set_gdbarch_stack_align (struct gdbarch *gdbarch, gdbarch_stack_align_ftype *stack_align);
+ #if (GDB_MULTI_ARCH > 1) || !defined (STACK_ALIGN)
+ #define STACK_ALIGN(sp) (gdbarch_stack_align (current_gdbarch, sp))
+ #endif
+ 
  extern struct gdbarch_tdep *gdbarch_tdep (struct gdbarch *gdbarch);
  
  
Index: valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.10
diff -p -r1.10 valops.c
*** valops.c	2000/04/17 02:27:37	1.10
--- valops.c	2000/04/20 07:49:30
*************** You must use a pointer to function type 
*** 1534,1547 ****
  	    arg_type = check_typedef (VALUE_ENCLOSING_TYPE (args[i]));
  	    len = TYPE_LENGTH (arg_type);
  
! #ifdef STACK_ALIGN
! 	    /* MVS 11/22/96: I think at least some of this stack_align code is
! 	       really broken.  Better to let PUSH_ARGUMENTS adjust the stack in
! 	       a target-defined manner.  */
! 	    aligned_len = STACK_ALIGN (len);
! #else
! 	    aligned_len = len;
! #endif
  	    if (INNER_THAN (1, 2))
  	      {
  		/* stack grows downward */
--- 1534,1547 ----
  	    arg_type = check_typedef (VALUE_ENCLOSING_TYPE (args[i]));
  	    len = TYPE_LENGTH (arg_type);
  
! 	    if (STACK_ALIGN_P ())
! 	      /* MVS 11/22/96: I think at least some of this
! 		 stack_align code is really broken.  Better to let
! 		 PUSH_ARGUMENTS adjust the stack in a target-defined
! 		 manner.  */
! 	      aligned_len = STACK_ALIGN (len);
! 	    else
! 	      aligned_len = len;
  	    if (INNER_THAN (1, 2))
  	      {
  		/* stack grows downward */
*************** You must use a pointer to function type 
*** 1583,1594 ****
    if (struct_return)
      {
        int len = TYPE_LENGTH (value_type);
! #ifdef STACK_ALIGN
!       /* MVS 11/22/96: I think at least some of this stack_align code is
!          really broken.  Better to let PUSH_ARGUMENTS adjust the stack in
!          a target-defined manner.  */
!       len = STACK_ALIGN (len);
! #endif
        if (INNER_THAN (1, 2))
  	{
  	  /* stack grows downward */
--- 1583,1593 ----
    if (struct_return)
      {
        int len = TYPE_LENGTH (value_type);
!       if (STACK_ALIGN_P ())
! 	/* MVS 11/22/96: I think at least some of this stack_align
! 	   code is really broken.  Better to let PUSH_ARGUMENTS adjust
! 	   the stack in a target-defined manner.  */
! 	len = STACK_ALIGN (len);
        if (INNER_THAN (1, 2))
  	{
  	  /* stack grows downward */
*************** You must use a pointer to function type 
*** 1609,1619 ****
     hppa_push_arguments */
  #ifndef NO_EXTRA_ALIGNMENT_NEEDED
  
- #if defined(STACK_ALIGN)
    /* MVS 11/22/96: I think at least some of this stack_align code is
       really broken.  Better to let PUSH_ARGUMENTS adjust the stack in
       a target-defined manner.  */
!   if (INNER_THAN (1, 2))
      {
        /* If stack grows down, we must leave a hole at the top. */
        int len = 0;
--- 1608,1617 ----
     hppa_push_arguments */
  #ifndef NO_EXTRA_ALIGNMENT_NEEDED
  
    /* MVS 11/22/96: I think at least some of this stack_align code is
       really broken.  Better to let PUSH_ARGUMENTS adjust the stack in
       a target-defined manner.  */
!   if (STACK_ALIGN_P () && INNER_THAN (1, 2))
      {
        /* If stack grows down, we must leave a hole at the top. */
        int len = 0;
*************** You must use a pointer to function type 
*** 1624,1630 ****
  	len += CALL_DUMMY_STACK_ADJUST;
        sp -= STACK_ALIGN (len) - len;
      }
- #endif /* STACK_ALIGN */
  #endif /* NO_EXTRA_ALIGNMENT_NEEDED */
  
    sp = PUSH_ARGUMENTS (nargs, args, sp, struct_return, struct_addr);
--- 1622,1627 ----
*************** You must use a pointer to function type 
*** 1642,1649 ****
    sp = PUSH_RETURN_ADDRESS (real_pc, sp);
  #endif /* PUSH_RETURN_ADDRESS */
  
! #if defined(STACK_ALIGN)
!   if (!INNER_THAN (1, 2))
      {
        /* If stack grows up, we must leave a hole at the bottom, note
           that sp already has been advanced for the arguments!  */
--- 1639,1645 ----
    sp = PUSH_RETURN_ADDRESS (real_pc, sp);
  #endif /* PUSH_RETURN_ADDRESS */
  
!   if (STACK_ALIGN_P () && !INNER_THAN (1, 2))
      {
        /* If stack grows up, we must leave a hole at the bottom, note
           that sp already has been advanced for the arguments!  */
*************** You must use a pointer to function type 
*** 1651,1657 ****
  	sp += CALL_DUMMY_STACK_ADJUST;
        sp = STACK_ALIGN (sp);
      }
- #endif /* STACK_ALIGN */
  
  /* XXX This seems wrong.  For stacks that grow down we shouldn't do
     anything here!  */
--- 1647,1652 ----
From ac131313@cygnus.com Thu Apr 20 01:30:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [RFC] Convert d10v's STACK_ALIGN; Was: [RFC] Convert STACK_ALIGN to multi-arch ....
Date: Thu, 20 Apr 2000 01:30:00 -0000
Message-id: <38FEBFF2.DCB46367@cygnus.com>
References: <38FEBAE3.D0FD616D@cygnus.com>
X-SW-Source: 2000-04/msg00389.html
Content-length: 1934

Hello,

The attatched is a follow-on to the previous STACK_ALIGN patch.  It
updates the d10v.

	Andrew
Thu Apr 20 18:15:08 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* d10v-tdep.c (d10v_gdbarch_init): Initialize stack_align.
	(d10v_stack_align): Make static.
	* config/d10v/tm-d10v.h (STACK_ALIGN): Delete.

Index: d10v-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/d10v-tdep.c,v
retrieving revision 1.2
diff -p -r1.2 d10v-tdep.c
*** d10v-tdep.c	2000/02/09 04:46:47	1.2
--- d10v-tdep.c	2000/04/20 08:25:38
*************** d10v_frame_chain_valid (chain, frame)
*** 104,110 ****
    return ((chain) != 0 && (frame) != 0 && (frame)->pc > IMEM_START);
  }
  
! CORE_ADDR
  d10v_stack_align (CORE_ADDR len)
  {
    return (len + 1) & ~1;
--- 104,110 ----
    return ((chain) != 0 && (frame) != 0 && (frame)->pc > IMEM_START);
  }
  
! static CORE_ADDR
  d10v_stack_align (CORE_ADDR len)
  {
    return (len + 1) & ~1;
*************** d10v_gdbarch_init (info, arches)
*** 1655,1660 ****
--- 1655,1661 ----
    set_gdbarch_frame_locals_address (gdbarch, d10v_frame_locals_address);
    set_gdbarch_saved_pc_after_call (gdbarch, d10v_saved_pc_after_call);
    set_gdbarch_frame_num_args (gdbarch, frame_num_args_unknown);
+   set_gdbarch_stack_align (gdbarch, d10v_stack_align);
  
    return gdbarch;
  }
Index: config/d10v/tm-d10v.h
===================================================================
RCS file: /cvs/src/src/gdb/config/d10v/tm-d10v.h,v
retrieving revision 1.2
diff -p -r1.2 tm-d10v.h
*** tm-d10v.h	2000/02/09 04:46:47	1.2
--- tm-d10v.h	2000/04/20 08:25:38
***************
*** 25,31 ****
  extern int d10v_register_sim_regno (int reg);
  #define REGISTER_SIM_REGNO(NR) d10v_register_sim_regno((NR))
  
- extern CORE_ADDR d10v_stack_align (CORE_ADDR size);
- #define STACK_ALIGN(SIZE) (d10v_stack_align (SIZE))
- 
  #define NO_EXTRA_ALIGNMENT_NEEDED 1
--- 25,28 ----
From eliz@delorie.com Thu Apr 20 02:24:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: jimb@cygnus.com
Cc: shebs@apple.com, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: Document RETURN_VALUE_ON_STACK
Date: Thu, 20 Apr 2000 02:24:00 -0000
Message-id: <200004200924.FAA15717@indy.delorie.com>
References: <200004181954.OAA08866@zwingli.cygnus.com> <38FCC3DD.533C7037@apple.com> <npitxfoxew.fsf@zwingli.cygnus.com> <200004190737.DAA14301@indy.delorie.com> <npya69o8rm.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-04/msg00390.html
Content-length: 456

> From: Jim Blandy <jimb@cygnus.com>
> Date: 19 Apr 2000 20:34:21 -0500
> 
> I think we should be using @deftypefn for everything; that will build
> a function index for us automatically.  No?

If that's what people prefer, I don't mind.

Personally, I dislike the @defXXX commands, because they violate the
Texinfo language rules (e.g., use unescaped braces).  Their handling
in makeinfo is a horrible kludge which has subtle problems and
idiosyncrasies.
From ac131313@cygnus.com Thu Apr 20 02:56:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Philippe De Muyter <phdm@macqel.be>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: PATCH/RFA free(NULL) bomb in printcmd.c
Date: Thu, 20 Apr 2000 02:56:00 -0000
Message-id: <38FED326.69E89A2B@cygnus.com>
References: <200004110900.LAA01874@mail.macqel.be>
X-SW-Source: 2000-04/msg00391.html
Content-length: 1288

Philippe De Muyter wrote:
> 
> Andrew Cagney wrote :
> > Um, I'm confused.  wouldn't it be easier to just delete the two cleanup
> > calls (the first, perhaphs, replaced with make_cleanup (null_cleanup,
> > NULL))?
> 
> Of course.  But I did not know if the number of cleanups mattered, so I made
> my change as small as possible.
> 
> [ 10 minutes reflexion and search ]
> 
> The current situation and my and your `fixes' would have caused memory leaks,
> because the intention of the programmer there was actually to `free (name)'
> and `free (filename)', but `make_cleanup' is called before `name' and `filename'
> are allocated.
> I now think I have the correct fix. OK to commit ?
> 
> Philippe De Muyter  <phdm@macqel.be>
> 
>         * printcmd.c (print_address_symbolic): Call `make_cleanup' with
>         `(free_current_contents, &x)', not `(free, x)'.
>         * utils.c (free_current_contents): Do not `free (NULL)'.

FYI,

Something wierd is going on.  For the d10v-elf target, FreeBSD 3.4
host.  I see the regression:

x/d &oct
0x2007dc0:	-1490098887
gdb in free(): warning: junk pointer, too high to make sense.
(gdb) FAIL: gdb.base/long_long.exp: x/d &oct

The warning appears all over the place.  It suggests that something is
corrupting one of those pointers.

	Andrew
From ac131313@cygnus.com Thu Apr 20 03:31:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Philippe De Muyter <phdm@macqel.be>, gdb-patches@sourceware.cygnus.com
Subject: Re: PATCH/RFA free(NULL) bomb in printcmd.c
Date: Thu, 20 Apr 2000 03:31:00 -0000
Message-id: <38FEDC0A.F915966C@cygnus.com>
References: <200004110900.LAA01874@mail.macqel.be> <38FED326.69E89A2B@cygnus.com>
X-SW-Source: 2000-04/msg00392.html
Content-length: 4051

Andrew Cagney wrote:

> > Philippe De Muyter  <phdm@macqel.be>
> >
> >         * printcmd.c (print_address_symbolic): Call `make_cleanup' with
> >         `(free_current_contents, &x)', not `(free, x)'.
> >         * utils.c (free_current_contents): Do not `free (NULL)'.
> 
> FYI,
> 
> Something wierd is going on.  For the d10v-elf target, FreeBSD 3.4
> host.  I see the regression:
> 
> x/d &oct
> 0x2007dc0:      -1490098887
> gdb in free(): warning: junk pointer, too high to make sense.
> (gdb) FAIL: gdb.base/long_long.exp: x/d &oct
> 
> The warning appears all over the place.  It suggests that something is
> corrupting one of those pointers.

The attached appears to work much better. The function wasn't cleaning
up when build_address_symbolic failed.  This led to a later cleanup call
freeing a garbage pointer on the stack.

Philippe, can you try it on your platform.

	Andrew
Thu Apr 20 17:39:11 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* defs.h, utils.c (free_current_contents): Change parameter to
 	void*.

	From Philippe De Muyter  <phdm@macqel.be>:
	* printcmd.c (print_address_symbolic): Call `make_cleanup' with
	`(free_current_contents, &x)', not `(free, x)'.
	* utils.c (free_current_contents): Do not `free (NULL)'.

	* printcmd.c (print_address_symbolic): Cleanup after a failed
	call to build_address_symbolic.

Index: defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.13
diff -p -r1.13 defs.h
*** defs.h	2000/03/30 18:54:28	1.13
--- defs.h	2000/04/20 10:17:47
*************** extern void restore_cleanups (struct cle
*** 354,360 ****
  extern void restore_final_cleanups (struct cleanup *);
  extern void restore_my_cleanups (struct cleanup **, struct cleanup *);
  
! extern void free_current_contents (char **);
  
  extern void null_cleanup (void *);
  
--- 354,360 ----
  extern void restore_final_cleanups (struct cleanup *);
  extern void restore_my_cleanups (struct cleanup **, struct cleanup *);
  
! extern void free_current_contents (void *);
  
  extern void null_cleanup (void *);
  
Index: printcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/printcmd.c,v
retrieving revision 1.3
diff -p -r1.3 printcmd.c
*** printcmd.c	2000/04/04 04:16:48	1.3
--- printcmd.c	2000/04/20 10:17:54
*************** print_address_symbolic (addr, stream, do
*** 562,573 ****
    int offset = 0;
    int line = 0;
  
!   struct cleanup *cleanup_chain = make_cleanup (free, name);
!   if (print_symbol_filename)
!     make_cleanup (free, filename);
  
    if (build_address_symbolic (addr, do_demangle, &name, &offset, &filename, &line, &unmapped))
!     return;
  
    fputs_filtered (leadin, stream);
    if (unmapped)
--- 562,576 ----
    int offset = 0;
    int line = 0;
  
!   /* throw away both name and filename */
!   struct cleanup *cleanup_chain = make_cleanup (free_current_contents, &name);
!   make_cleanup (free_current_contents, &filename);
  
    if (build_address_symbolic (addr, do_demangle, &name, &offset, &filename, &line, &unmapped))
!     {
!       do_cleanups (cleanup_chain);
!       return;
!     }
  
    fputs_filtered (leadin, stream);
    if (unmapped)
Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.6
diff -p -r1.6 utils.c
*** utils.c	2000/03/30 18:54:28	1.6
--- utils.c	2000/04/20 10:17:59
*************** restore_my_cleanups (pmy_chain, chain)
*** 375,384 ****
     to arrange to free the object thus allocated.  */
  
  void
! free_current_contents (location)
!      char **location;
  {
!   free (*location);
  }
  
  /* Provide a known function that does nothing, to use as a base for
--- 375,385 ----
     to arrange to free the object thus allocated.  */
  
  void
! free_current_contents (void *ptr)
  {
!   void **location = ptr;
!   if (*location != NULL)
!     free (*location);
  }
  
  /* Provide a known function that does nothing, to use as a base for
From ac131313@cygnus.com Thu Apr 20 04:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Tim Mooney <mooney@dogbert.cc.ndsu.nodak.edu>
Cc: "Daniel Berlin+gnu.gdb.bug" <dan@cgsoftware.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [RFA]: Fix crashing bug in set follow-fork-mode
Date: Thu, 20 Apr 2000 04:00:00 -0000
Message-id: <38FEE2A9.E83C0059@cygnus.com>
References: <Pine.OSF.4.21.0004162124380.31138-100000@dogbert.cc.ndsu.nodak.edu>
X-SW-Source: 2000-04/msg00393.html
Content-length: 2902

Tim Mooney wrote:
>
> >Someone please commit this to the branch if it gets approved.
> >I have no idea how to make a testcase for it.
> >I knew something screwy was up when "set follow-fork-mode parent" said
> >"ambiguous command: \"parent\"", and it clearly wasn't ambiguous at
> >all.

> >So, i looked, and it had trashed our stack, and thought we had 6
> >million matches, rather than one.
> 
> scheduler-lock seems to have the same problem (see the enum at line 765 of
> infrun.c).  Conditions under which it happens are the exact same as in my
> report for the follow-fork-mode problem.  I've left the patch to fix the
> problem for you or someone else, since it's again very small.

Thanks!

I've applied the attatched to the 5.0 branch and trunk. Anyone come up
with a testsuite addition to add to the trunk?

	Andrew
Thu Apr 20 18:54:15 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	From Daniel Berlin <dan@cgsoftware.com> and Tim Mooney
 	<mooney@dogbert.cc.ndsu.nodak.edu>:
	* infrun.c (follow_fork_mode_kind_names): NULL terminate
 	array. Re-indent.
	(scheduler_enums): Ditto.

Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.7
diff -p -r1.7 infrun.c
*** infrun.c	2000/04/13 10:22:22	1.7
--- infrun.c	2000/04/20 10:32:34
*************** static int follow_vfork_when_exec;
*** 436,448 ****
  
  static char *follow_fork_mode_kind_names[] =
  {
! /* ??rehrauer:  The "both" option is broken, by what may be a 10.20
!    kernel problem.  It's also not terribly useful without a GUI to
!    help the user drive two debuggers.  So for now, I'm disabling
!    the "both" option.
!    "parent", "child", "both", "ask" };
!  */
!   "parent", "child", "ask"};
  
  static char *follow_fork_mode_string = NULL;
  \f
--- 436,448 ----
  
  static char *follow_fork_mode_kind_names[] =
  {
!   /* ??rehrauer: The "both" option is broken, by what may be a 10.20
!      kernel problem.  It's also not terribly useful without a GUI to
!      help the user drive two debuggers.  So for now, I'm disabling the
!      "both" option. */
!   /* "parent", "child", "both", "ask" */
!   "parent", "child", "ask", NULL
! };
  
  static char *follow_fork_mode_string = NULL;
  \f
*************** static char schedlock_on[] = "on";
*** 762,768 ****
  static char schedlock_step[] = "step";
  static char *scheduler_mode = schedlock_off;
  static char *scheduler_enums[] =
! {schedlock_off, schedlock_on, schedlock_step};
  
  static void
  set_schedlock_func (char *args, int from_tty, struct cmd_list_element *c)
--- 762,773 ----
  static char schedlock_step[] = "step";
  static char *scheduler_mode = schedlock_off;
  static char *scheduler_enums[] =
! {
!   schedlock_off,
!   schedlock_on,
!   schedlock_step,
!   NULL
! };
  
  static void
  set_schedlock_func (char *args, int from_tty, struct cmd_list_element *c)
From dan@cgsoftware.com Thu Apr 20 09:48:00 2000
From: dan@cgsoftware.com (Daniel Berlin+list.gdb-patches)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Tim Mooney <mooney@dogbert.cc.ndsu.nodak.edu>, "Daniel Berlin+gnu.gdb.bug" <dan@cgsoftware.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [RFA]: Fix crashing bug in set follow-fork-mode
Date: Thu, 20 Apr 2000 09:48:00 -0000
Message-id: <d7nk3ehd.fsf@dan.resnet.rochester.edu>
References: <Pine.OSF.4.21.0004162124380.31138-100000@dogbert.cc.ndsu.nodak.edu> <38FEE2A9.E83C0059@cygnus.com>
X-SW-Source: 2000-04/msg00394.html
Content-length: 696

Andrew Cagney <ac131313@cygnus.com> writes:

I have a better idea.

I just made it check the enum list, when the command is added, like
so:

while(1)
{
	if enumlist[i]==0
		break (this means it's properly null terminated)
	if (!isalnum(enumlist[i][0]))
		internal_error("<command name>'s enum list is not null
terminated, or contains non-alphanumeric characters.");
	i++;
}

This is better than the testsuite addition, because if you screw up,
gdb won't start, or it'll crash (it depends on where enumlist[i][0] is
located.)
Watch:
bash-2.03# ./gdb -nw
gdb-internal-error: follow-fork-mode has non-null terminated enum list, or non alpha-numeric character in enum list
bash-2.03#

Patch attached
From law@cygnus.com Thu Apr 20 10:20:00 2000
From: Jeffrey A Law <law@cygnus.com>
To: Alexandre Oliva <aoliva@cygnus.com>
Cc: binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: AM33 disassembler: fix for long-standing bug 
Date: Thu, 20 Apr 2000 10:20:00 -0000
Message-id: <5434.956247166@upchuck>
References: <orzoqqv7ux.fsf@zecarneiro.lsd.ic.unicamp.br>
X-SW-Source: 2000-04/msg00395.html
Content-length: 650

  In message < orzoqqv7ux.fsf@zecarneiro.lsd.ic.unicamp.br >you write:
  > --=-=-=
  > 
  > As written in the previous message, AM30 insns are *not* supposed to
  > be accepted on AM33.  However, I'd still like to install a patch like
  > this, to keep the platform-detection code identical to that in gas.
  > Ok to install?
  > 
  > 
  > --=-=-=
  > Content-Type: text/x-patch
  > Content-Disposition: inline; filename=am33-opcodes-fix.patch
  > 
  > Index: opcodes/ChangeLog
  > by  Alexandre Oliva  <aoliva@cygnus.com>
  > 
  > 	* m10300-dis.c (HAVE_AM30, HAVE_AM33): Define.
  > 	(disassemble): Use them.
This is fine.  Please install it.
jeff