Re: gdb.texinfo broken?

[Dmitry Sivachenko <dima@Chg.RU>]

Please, do not hurry to back out @dircategory!
It was introduced somewhere in texinfo-3.*!  The problem is somewhere else.
I'll try to figure it out...

--dima
From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Stephane Carrez <Stephane.Carrez@worldnet.fr>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <npem8w42bg.fsf@zwingli.cygnus.com>
References: <38D4DCB0.88313CB2@worldnet.fr> <38D5B6E0.50FF6A5E@cygnus.com> <38D68C56.856CB00C@worldnet.fr> <38D74A9E.A85ED8EC@cygnus.com> <38D7E6BC.79543EBA@worldnet.fr>
X-SW-Source: 2000-q1/msg01063.html
Content-length: 1641

I've reached the same conclusion on a project I'm doing right now.  I
think this test is bogus.


> > Rather than diging values out of archures I think the possibility of:
> >         cu_header.address_size < elf-header.address_size
> > should be documented as being just as legetimate (sarcasm :-) as:
> >         cu_header.address_size > elf-header.address_size
> > and the check either replaced or removed.
> > 
> >         Andrew
> 
> Ok, lets remove the strange test (it does not exist in bfd/dwarf2.c
> nor in readelf.c...)
> 
> Thanks,
> 	Stephane
>  
> 2000-03-21  Stephane Carrez  <stcarrez@worldnet.fr>
> 
> 	* dwarf2read.c (dwarf2_build_psymtabs_hard): Do not check
> 	the dwarf address size against elf address size.
> --------------171FF77269274D1E5CFD870E
> Content-Type: text/plain; charset=us-ascii;
>  name="dwarf2read.c.diff"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
>  filename="dwarf2read.c.diff"
> 
> --- /src/gnu/cygnus/gdb/gdb/dwarf2read.c	Sat Mar  4 11:38:38 2000
> +++ gdb/dwarf2read.c	Tue Mar 21 20:50:13 2000
> @@ -980,12 +980,6 @@ dwarf2_build_psymtabs_hard (objfile, mai
>  		 (long) (beg_of_comp_unit - dwarf_info_buffer));
>  	  return;
>  	}
> -      if (address_size < address_significant_size)
> -	{
> -	  error ("Dwarf Error: bad address size (%ld) in compilation unit header (offset 0x%lx + 11).",
> -		 (long) cu_header.addr_size,
> -		 (long) (beg_of_comp_unit - dwarf_info_buffer));
> -	}
>  
>        /* Read the abbrevs for this compilation unit into a table */
>        dwarf2_read_abbrevs (abfd, cu_header.abbrev_offset);
> 
> --------------171FF77269274D1E5CFD870E--
> 
> 
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Jim Kingdon <kingdon@redhat.com>, msnyder@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: GDB 5.0 2000-03-05
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000307161242.A485@lucon.org>
References: <38C2320A.E2134B29@cygnus.com> <20000305094341.A10426@lucon.org> <br9dojaan.fsf@rtl.cygnus.com> <20000306094553.B28105@lucon.org> <200003061753.MAA14567@devserv.devel.redhat.com>
X-SW-Source: 2000-q1/msg00567.html
Content-length: 3599

On Mon, Mar 06, 2000 at 12:53:59PM -0500, Jim Kingdon wrote:
> > Do you have URL for the bug report.
> 
> As noted on issues50.html,
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=9565
> The Mozilla folks would be *very* happy if someone can track this one down.
> 

This patch disable the thread_db interface by default. gdb works MUCH
better now with threaded programs, including the testcase above. May
I suggest for 5.0, we disable thread_db and fix whatever bugs we can
fix in linux-thread.c? I will take a closer look at linux-thread.c
when I find time.

Thanks.


H.J.
---
2000-03-07  H.J. Lu  <hjl@gnu.org>

	* Makefile.in (LIN_THREAD): New.
	(LIN_THREAD_CFLAGS): New.
	(INTERNAL_WARN_CFLAGS): Add $(LIN_THREAD_CFLAGS).

	* config/i386/linux.mh (NATDEPFILES): Change lin-thread.o to
	$(LIN_THREAD).

	* configure.in (--enable-thread_db): New switch. Set LIN_THREAD
	and LIN_THREAD_CFLAGS accordingly.
	* configure: Regenerated.

Index: configure.in
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/configure.in,v
retrieving revision 1.1.1.6
diff -u -p -r1.1.1.6 configure.in
--- configure.in	2000/03/07 18:42:10	1.1.1.6
+++ configure.in	2000/03/07 23:47:24
@@ -789,6 +807,26 @@ AC_SUBST(CONFIG_ALL)
 AC_SUBST(CONFIG_CLEAN)
 AC_SUBST(CONFIG_INSTALL)
 AC_SUBST(CONFIG_UNINSTALL)
+
+# Begin stuff to support --enable-thread_db
+AC_ARG_ENABLE(thread_db,
+[  --enable-thread_db         Use the thread_db interface],
+[case "${enableval}" in
+  yes) thread_db=true ;;
+  no)  thread_db=false ;;
+  *) thread_db=true;;
+esac])dnl
+
+LIN_THREAD=
+LIN_THREAD_CFLAGS=
+if test "${thread_db}" = "true"; then
+  LIN_THREAD="lin-thread.o"
+  LIN_THREAD_CFLAGS="-DUSE_LIN_THREAD"
+fi
+
+AC_SUBST(LIN_THREAD)
+AC_SUBST(LIN_THREAD_CFLAGS)
+# End stuff to support --enable-shared
 
 # Begin stuff to support --enable-shared
 AC_ARG_ENABLE(shared,
Index: Makefile.in
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/Makefile.in,v
retrieving revision 1.1.1.9
diff -u -p -r1.1.1.9 Makefile.in
--- Makefile.in	2000/03/07 18:42:08	1.1.1.9
+++ Makefile.in	2000/03/07 23:28:45
@@ -114,6 +114,10 @@ LIBIBERTY = ../libiberty/libiberty.a
 MMALLOC = @MMALLOC@
 MMALLOC_CFLAGS = @MMALLOC_CFLAGS@
 
+# Configured by the --enable-thread_db configure.
+LIN_THREAD = @LIN_THREAD@
+LIN_THREAD_CFLAGS = @LIN_THREAD_CFLAGS@
+
 # Where is the BFD library?  Typically in ../bfd.
 BFD_DIR = ../bfd
 BFD = $(BFD_DIR)/libbfd.a
@@ -271,7 +275,8 @@ INTERNAL_WARN_CFLAGS = \
 	$(CFLAGS) $(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) \
 	$(GDB_CFLAGS) $(OPCODES_CFLAGS) $(READLINE_CFLAGS) \
 	$(BFD_CFLAGS) $(MMALLOC_CFLAGS) $(INCLUDE_CFLAGS) \
-	$(INTL_CFLAGS) $(TUI_CFLAGS) $(ENABLE_CFLAGS) $(GDB_WARN_CFLAGS)
+	$(INTL_CFLAGS) $(TUI_CFLAGS) $(ENABLE_CFLAGS) \
+	$(LIN_THREAD_CFLAGS) $(GDB_WARN_CFLAGS)
 INTERNAL_CFLAGS = $(INTERNAL_WARN_CFLAGS) $(GDB_WERROR_CFLAGS)
 
 # LDFLAGS is specifically reserved for setting from the command line
Index: config/i386/linux.mh
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/config/i386/linux.mh,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 linux.mh
--- config/i386/linux.mh	2000/01/18 17:07:18	1.1.1.2
+++ config/i386/linux.mh	2000/03/07 23:44:03
@@ -5,6 +5,6 @@ XDEPFILES= ser-tcp.o
 
 NAT_FILE= nm-linux.h
 NATDEPFILES= infptrace.o solib.o inftarg.o fork-child.o corelow.o \
-	core-aout.o i386v-nat.o i386-linux-nat.o linux-thread.o lin-thread.o
+	core-aout.o i386-linux-nat.o linux-thread.o $(LIN_THREAD)
 
 LOADLIBES = -ldl -rdynamic
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Steven Johnson <sbjohnson@ozemail.com.au>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFA: Deprecate remote protocol sequence-ID
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DB24AB.7881FFA1@cygnus.com>
References: <38DAF122.3CA0E862@cygnus.com> <38DB0EE5.831CD611@ozemail.com.au>
X-SW-Source: 2000-q1/msg00981.html
Content-length: 1685

Steven Johnson wrote:
> 
> Andrew Cagney wrote:
> >
> > I'd like to put forward the proposal that the sequence-id:
> >
> > $sequence-id:packet-data#checksum
> >
> > be clearly deprecated.
> 
> I would actually prefer to see it properly defined to secure up
> communications between
> the target and GDB. (Obviously it would be selectable)

I agree that there should be a properly defined mechanism for reliably
transfering packets, just not this one as it affects the contents of a
packet.  The good old theory of a clear separation of layers :-)

I think a simple reliable separate transport layer is needed.  I'd even
go as far as a new packet wrapper (replacing $...#NN and +-).

> Can you give an example of how it restricts packet contents, other than
> having a colon as the third character in the packet.

That, to me is sufficient.

> A Target i'm writing can use them and seem to work fine? Although Ive
> had to make some interpretations in implementation because they are not well
> defined.

That ``not well defined'' bit is my problem.  GDB can't rely on what a
target will do with a sequence-id because it is not well defined.  The
target might discard the packet.  The target might reply with the
contents from the last output buffer, the target might even just repeat
the operation (oops :-).

> Further if the Colon at position 3 is a problem, then don't use it. It
> seems to me
> that a function code of '0'-'9' is not used, so it would be easy to
> detect these functions
> and say 'Now using sequence-id' must check colon for verification. (Also
> I check second character and it also must be 0-9.)

Interesting idea.  None of the targets I know do this.

	Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Geoff Keating <geoffk@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: patch to psim for denormal values
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DC5F3A.FE48DC2A@cygnus.com>
References: <200003250008.QAA31192@localhost.cygnus.com>
X-SW-Source: 2000-q1/msg01019.html
Content-length: 346

Geoff Keating wrote:
> 
> gcc/testsuite/gcc.c-torture/execute/ieee/20000320-1.c was sending the
> sim into a very long (perhaps infinite) loop, because of this typo.

Wow! A bug :-)

> My copy of the ppc 601 user's manual correctly uses '+' here (on page
> F-2).

Oops, nothing like copying it down wrong.

> OK to commit?

Yes. Thanks.

	Andrew
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: shebs@shebs.cnchost.com, dima@Chg.RU, 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: <5mu2jrmjqt.fsf@jtc.redbacknetworks.com>
References: <200001281642.TAA04176@netserv1.chg.ru> <3891CD13.A68984BA@shebs.cnchost.com> <200001281909.e0SJ97M18034@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00067.html
Content-length: 1298

>>>>> "Mark" == Mark Kettenis <kettenis@wins.uva.nl> writes:
Mark> Cygnus might do things a little different.  Is GDB still
Mark> distributed with texinfo included?  The CVS version suggests
Mark> that this is the case.  Since the version in CVS is older than
Mark> texinfo 4.0, using new features would not be very convenient!
Mark> Maybe it is time for an upgrade?  

The full texinfo distribution is not distributed with GDB releases, at
least it wasn't with gdb-4.16, 4.17, or 4.18.  Those releases provided
only texinfo.tex, gpl.texinfo, lgpl.texinfo, and tex3patch.  

However, a modified texinfo-3.2 is still distributed in GDB snapshots.
I managed to overwrite texinfo-4.0 on my system after installing a GDB
snapshot.  I mentioned this at the time, hoping that texinfo would be
dropped from snapshots.  Ultimately, I changed my import procedure to
remove texinfo before importing new snapshots into my own repository.

I notice that the binutils repository on sourceware only contains
texinfo.tex in it's texinfo directory.  Now that the binutils and GDB
repositories are being merged, perhaps this problem will go away.  I
hope that the reverse is not true and that binutils is not similarly
tainted with a obsolete texinfo distribution.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: "H . J . Lu" <hjl@lucon.org>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A revised patch for dlclose
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C69870.709F@cygnus.com>
References: <20000307120800.A27315@valinux.com> <200003080058.e280wga00453@delius.kettenis.local> <20000307170321.A884@lucon.org> <200003080119.e281Jul00524@delius.kettenis.local> <20000307173547.A1068@lucon.org>
X-SW-Source: 2000-q1/msg00598.html
Content-length: 1507

H . J . Lu wrote:
> 
> On Wed, Mar 08, 2000 at 02:19:56AM +0100, Mark Kettenis wrote:
> >    Date: Tue, 7 Mar 2000 17:03:21 -0800
> >    From: "H . J . Lu" <hjl@lucon.org>
> >    Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
> >    Content-Type: text/plain; charset=us-ascii
> >
> >    > HJ, please stop wasting your time pushing this patch.  The patch has
> >    > several bad points, that you cannot fix without considerable changes
> >    > to the way solib.c handles and caches the link map.
> >
> >    I just pointed out gdb needed to check the unloaded DSOs when handling
> >    the BPSTAT_WHAT_CHECK_SHLIBS and BPSTAT_WHAT_CHECK_SHLIBS_RESUME_FROM_HOOK
> >    events. It is a serious bug to me and it should be fixed in 5.0. I
> >    don't care how it is fixed.
> >
> > But I, and I hope most of the other GDB maintainers, do care how it is
> > fixed!
> 
> That is fine with me as long as it is fixed in 5.0. There is no excuse
> not to get gdb to work with dlclose. "I don't like the way it fixes the
> bug" doesn't count unless you can provide a different approach. I
> think it is unreasonable to have a perfect fix for every bug. We can
> work a better one after 5.0 if we don't have the time now.

I'm sorry, but I have to disagree.  I'm not addressing your
patch in particular, but there are many "fixes" that are 
worse than no fix at all.  In fact, GDB is full of them, 
to our (the maintainers) daily regret.  There is never time
to fix it right the second time.

Michael
From Peter.Schauer@regent.e-technik.tu-muenchen.de Sat Apr 01 00:00:00 2000
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: maint.c: Add `mt i' alias for `mt info'
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003271537.RAA03867@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-q1/msg01056.html
Content-length: 988

I have been used to issue e.g. `maint i sec'. Due to the new
`maint internal-error' command, `maint i sec' is now ambigous.

I could live with this, but as the top level `info' command can be abbreviated
via `i', GDB should be consistent and allow the same for `mt info'.

Here is a patch:

2000-03-27  Peter Schauer  <pes@regent.e-technik.tu-muenchen.de>

	* maint.c (_initialize_maint_cmds):  Add `mt i' alias for `mt info'.

--- gdb/maint.c.orig	Thu Sep  9 01:59:19 1999
+++ gdb/maint.c	Sat Mar 25 20:46:19 2000
@@ -375,6 +375,7 @@ to test internal functions such as the C
      "Commands for showing internal info about the program being debugged.",
 		  &maintenanceinfolist, "maintenance info ", 0,
 		  &maintenancelist);
+  add_alias_cmd ("i", "info", class_maintenance, 1, &maintenancelist);
 
   add_cmd ("sections", class_maintenance, maintenance_info_sections,
 	   "List the BFD sections of the exec and core files.",

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH RFA] symfile.c bounds check
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000318223035.ZM11861@ocotillo.lan>
X-SW-Source: 2000-q1/msg00774.html
Content-length: 1202

I was seeing rather severe problems (gdb coredumps; test suite
wouldn't run at all) on linux/ppc after my recent solib.c changes. 
The following patch fixes these problems.  (Also, since this is happening,
MAX_SECTIONS needs to be even bigger.  We probably just ought to
redesign struct section_addr_info so that it can be dynamically sized.)

May I check this in?

	* symfile.c (syms_from_objfile): Added bounds check prior to
	accessing ``other'' array in a section_addr_info struct.

Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.2
diff -u -p -r1.2 symfile.c
--- symfile.c	2000/03/15 19:43:57	1.2
+++ symfile.c	2000/03/18 22:18:53
@@ -738,7 +790,9 @@ syms_from_objfile (objfile, addrs, mainl
  	  else if (strcmp (s->the_bfd_section->name, ".bss") == 0)
  	    s_addr = addrs->bss_addr;
  	  else 
- 	    for (i = 0; !s_addr && addrs->other[i].name; i++)
+ 	    for (i = 0; 
+	         !s_addr && i < MAX_SECTIONS && addrs->other[i].name;
+		 i++)
  	      if (strcmp (s->the_bfd_section->name, addrs->other[i].name) == 0)
  	        s_addr = addrs->other[i].addr; /* end added for gdb/13815 */