From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Sivachenko To: jtc@redback.com Cc: msnyder@cygnus.com, eliz@is.elta.co.il, gdb-patches@sourceware.cygnus.com Subject: Re: gdb.texinfo broken? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003230901.MAA46705@netserv1.chg.ru> References: <38D6CF69.6844@cygnus.com> <200003211819.NAA12435@indy.delorie.com> <38D7C977.FA3@cygnus.com> <5mitygglxs.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00936.html 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 To: Stephane Carrez Cc: Andrew Cagney , 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: 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 > > * 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" To: Jim Kingdon , 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> <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 * 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 To: Steven Johnson Cc: GDB Patches 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 To: Geoff Keating 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 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 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 To: "H . J . Lu" Cc: Mark Kettenis , 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" > > 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" 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 * 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 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 */