Re: patch for gdb.texinfo

[Stan Shebs <shebs@shebs.cnchost.com>]

(Hi everybody!)

Dmitry Sivachenko wrote:
> 
> >
> > > -intent is to aid the debugging of @dfn{dynamic arrays}, which cannot be
> > > +intent is to aid the debugging of dynamic arrays, which cannot be
> >
> > Why is it a good idea to remove the @dfn here?
> 
> Because there is no definition of 'dynamic arrays' here in the text.

Which makes sense, although perhaps it would be better to include
a quick definition of dynamic arrays.  The reader may or may not
know what is being referred to here - indeed I'm not entirely sure
myself, although the term seems to be used in a generic sense,
rather than as a reference to a specific language construct.

> > As for the replacements of @code and @samp with @env and @option:
> > please note that this makes the GDB manual incompatible with all
> > versions of Texinfo except the latest v4.0.
> 
> That is true.
> 
> > Are you sure it's a good
> > idea to break back-compatibility for no good reason (since they
> > typeset in the same way)?
> 
> Do you use any new features of whatever OS you use?  This is also
> incompatible with older versions...
> 
> I think we should use new features of texinfo.  May be in future versions
> typeseting @env and @command  will differ from the current behaviour.
> By the way, FreeBSD team already updated texinfo to 4.0 in base distribution.

I disagree here.  We do have to worry about backward compatibility,
just as we had to support K&R compilers for a long time, and just
as we support many old OS versions.  Certainly many GDB users would
be disappointed if we trashed Linux support for any kernel older
than, say, 2.2.5!

In the case at hand, older versions of texinfo will just choke and
stop processing the file, right?  So to forestall many bug reports,
we should stick with an older version.  I would say 3.0, but if
somebody knows of a need for compat with 2.x, speak up now...

                                                Stan
                                                shebs@shebs.cnchost.com
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ezannoni@cygnus.com
Cc: shebs@apple.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Handle_inferior_event() problem
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003091332.IAA19945@indy.delorie.com>
References: <14533.28395.325377.920332@kwikemart.cygnus.com>
X-SW-Source: 2000-q1/msg00616.html
Content-length: 511

> Say you have stepped your way to the first instruction of the prologue
> of a function (using stepi, for instance) and now you do a 'nexti'.
> The programs runs away to the end of the function or somewhere else and
> gdb gets really confused.

Confirmed in the DJGPP version: the problem exists just like you
described.

> Anyway, long story short...  How about this patch? It doesn't take
> care of everything, but it solves that immediate problem.

Confirmed again: problem solved with this patch.  Thanks!
From Julian.Bock@t-online.de Sat Apr 01 00:00:00 2000
From: Julian.Bock@t-online.de (Julian v. Bock)
To: gdb-patches@sourceware.cygnus.com
Subject: gdb 4.18 / libiberty bugfix
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <00011802175801.00321@KernelPanic>
X-SW-Source: 2000-q1/msg00024.html
Content-length: 690

Hi!

problem:
gdb segfaulted when demangling a (rather complex) c++ name while reading a
symbol table.

bug:
In the remember_type function (gdb-4.18/libiberty/cplus-dem.c) the typevec
array of the work structure was zero, but work -> typevec_size was 3, so the
function didn't allocate memory for typevec. When typevec was accessed gdb
went down.
The reason for this seems to be that when work -> typevec is freed in the mop_up
function (same file; line 882) work -> typevec_size is not set zero.

solution:
setting work -> typevec_size to zero after freeing work -> typevec should do
the trick. After I have done this everything worked fine.

I hope this bug wasn't already known.

Julian
From cgf@cygnus.com Sat Apr 01 00:00:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [PATCH} maint.c remove quoted trailing space
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000325193022.H802@cygnus.com>
References: <38DC70E4.C2ECB4E9@cygnus.com>
X-SW-Source: 2000-q1/msg01031.html
Content-length: 279

On Sat, Mar 25, 2000 at 06:55:16PM +1100, Andrew Cagney wrote:
>I've applied the following.  As an aside, we can start using:
>
>	"a string that"
>	"extends over several lines"

But this only works in ISO C!

Oh.  Wait.  Never mind.

I always forget that you can do this...

cgf
From scottb@netwinder.org Sat Apr 01 00:00:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Patches and the patch database...
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BEC141.9D299C3B@netwinder.org>
X-SW-Source: 2000-q1/msg00460.html
Content-length: 427

Hi guys,

I decided to exercise the patch database.  I sent a whole whack of patches to
get rid of the deprecated macros TARGET_BYTE_ORDER and
TARGET_BYTE_ORDER_SELECTABLE.  It might be useful to have an architecture field
on the web form.  That would make it easier to search for ARM patches for
instance.

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: gdbarch_free
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <nphfe89jwc.fsf@zwingli.cygnus.com>
References: <200002282302.SAA13215@zwingli.cygnus.com> <38BB1A9A.61A680AA@cygnus.com> <npg0ualjj3.fsf@zwingli.cygnus.com> <38C223E1.43260416@cygnus.com> <npk8j49nv0.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg00718.html
Content-length: 1703

> > > > >From memory, I figured that if an _initialize* function failed to create
> > > > a gdbarch the process was somewhat hosed and calling internal_error()
> > > > was probably the best thing to do.
> > 
> > > This situation could arise if someone adds support for a new variant
> > > of my architecture, but hasn't updated GDB yet.
> > 
> > So the real question is, is this an internal_error() and how should
> > it be handled?  I can be convinced either way on this :-)
> 
> No, it's okay, I'll just drop the memory.  I withdraw the patch.

Well, actually...

I don't think this is an internal error.  It's simply a case where GDB
has been given an executable that it doesn't recognize.  That
executable may have been produced by a completely different toolchain.

GDB gets the architecture and the machine (a variant within an
architecture, like 32-bit or 64-bit) from BFD.  BFD gets the
architecture from the ELF header's e_machine field (note the
unfortunate conflict in terminology), and gets the machine by masking
off some bits of the ELF header's e_flags field.

Suppose e_flags uses a three-bit field to identify the machine
variant, and uses 001 and 010 to identify two existing variants.  In
my foo_gdbarch_init function, I can recognize 001 and 010, but what
should I do with other values?

If I'm using a newer toolchain with an older GDB executable, this
situation could certainly arise, and GDB should report it nicely.

I guess I don't see the rationale for assuming that nobody will ever
put anything in an executable file that some GDB *_gdbarch_init
function won't recognize.  GDB should print an error message.

This isn't an internal error: the source of the data is external.
From taylor@cygnus.com Sat Apr 01 00:00:00 2000
From: David Taylor <taylor@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] Another utils.c patch
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003202011.PAA22504@texas.cygnus.com>
X-SW-Source: 2000-q1/msg00822.html
Content-length: 1799

    Date: Mon, 20 Mar 2000 12:35:19 -0700
    From: Kevin Buettner <kevinb@cygnus.com>

    On Mar 20, 12:45pm, David Taylor wrote:

    >        memcpy (&dfrom, from, sizeof (dfrom));
    >     -  memset (uto, 0, fmt->totalsize / FLOATFORMAT_CHAR_BIT);
    >     +  memset (uto, 0, fmt->totalsize / FLOATFORMAT_CHAR_BIT
    >     +                  + ((fmt->totalsize % FLOATFORMAT_CHAR_BIT) == 0 ? 0 : 1));
    > 
    > Approved.

    Thanks for approving this so quickly.  However, I had withdrawn the
    above patch in favor of the one below.  I would prefer to get approval
    for the one below.  They are, however, functionally equivalent.  If
    you prefer the one above for some reason, I can check that one in
    instead.

Either version is okay; I prefer the newer one, but either is acceptable.

	    * utils.c (floatformat_from_doublest): Make sure space that we're
	    writing the float to is completely initialized to zeroes, even
	    when the number of bits in the float is not evenly divisible
	    by FLOATFORMAT_CHAR_BIT.

    Index: utils.c
    ===================================================================
    RCS file: /cvs/src/src/gdb/utils.c,v
    retrieving revision 1.4
    diff -u -p -r1.4 utils.c
    --- utils.c     2000/03/04 02:23:06     1.4
    +++ utils.c     2000/03/19 17:36:49
    @@ -2722,7 +2722,8 @@ floatformat_from_doublest (fmt, from, to
       unsigned char *uto = (unsigned char *) to;

       memcpy (&dfrom, from, sizeof (dfrom));
    -  memset (uto, 0, fmt->totalsize / FLOATFORMAT_CHAR_BIT);
    +  memset (uto, 0, (fmt->totalsize + FLOATFORMAT_CHAR_BIT - 1) 
    +                    / FLOATFORMAT_CHAR_BIT);
       if (dfrom == 0)
	 return;                    /* Result is zero */
       if (dfrom != dfrom)          /* Result is NaN */