From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: Dmitry Sivachenko Cc: eliz@is.elta.co.il, gdb-patches@sourceware.cygnus.com Subject: Re: patch for gdb.texinfo Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <3891CD13.A68984BA@shebs.cnchost.com> References: <200001281642.TAA04176@netserv1.chg.ru> X-SW-Source: 2000-q1/msg00041.html (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 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 To: Andrew Cagney Cc: GDB Patches 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 To: GDB Patches Mail List 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 To: Jim Blandy Cc: Andrew Cagney , gdb-patches@sourceware.cygnus.com Subject: Re: RFA: gdbarch_free Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <200002282302.SAA13215@zwingli.cygnus.com> <38BB1A9A.61A680AA@cygnus.com> <38C223E1.43260416@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 To: Kevin Buettner 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 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 */