From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Edwards To: Fernando Nasser Cc: Andrew Cagney , Fernando Nasser , gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000225091418.B3106@visi.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> <38B61CF6.B4F80802@cygnus.com> <38B69A2A.ED2DC6F3@redhat.com> X-SW-Source: 2000-q1/msg00419.html On Fri, Feb 25, 2000 at 03:05:14PM +0000, Fernando Nasser wrote: > > It's more a question of should the endianess have changed between > > releases or should it have been little-endian anyway. Not my problem > > :-) > > I inherited this one :-) > > But you are right, this will at least require an entry in the > NEWS, as it alters some previous behavior. *If* the arm users > in the list decide that the default should be little-endian. >From what I've seen/read little-endian is more common (does ARM-Linux run little-endian or big?), and it's the default for gcc/binutils, so it should probably be the default for gdb as well. I was just confused because I thought "auto" meant that it would be determined by the target. > It does seem reasonable and if the file command straights it > out, only the load users would have to care (but they are more > aware of these issues, and can always have the set endian on > their .gdbinit). Having the load command warn the user if the target and file differ might also be something to consider. > It is a shame that Angel is so buggy. The return code should > appropriately indicate the endianess of the target -- it would > be a nice feature to use :-( Does Angel not report it correctly? The ARM EmbeddedICE is broken in that respect, but I don't have a copy of Angel running anywhere. -- Grant Edwards grante@visi.com >From dan@cgsoftware.com Sat Apr 01 00:00:00 2000 From: dan@cgsoftware.com (Daniel Berlin+list.gdb-patches) To: gdb@sourceware.cygnus.com Subject: C++ Overload testsuite fixes, need someone to verify Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: X-SW-Source: 2000-q1/msg00786.html Content-length: 413 Can someone verify, that i am correct in thinking you get unexpected failures in gdb.c++/ovldbreak.exp due to "breakpoint info" failures? I have a patch, i just want to make sure it's not me. It appears the source line the test suite expects main to appear on in that file is 49, and main really appears at 48, so the regex to match doesn't work. I diffed the ovldbreak.cc file, and i get no differences. --Dan >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: gdb@sourceware.cygnus.com Subject: annotate.texi Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003070832.DAA14451@indy.delorie.com> X-SW-Source: 2000-q1/msg00557.html Content-length: 433 Is there any reason why annotate.texi shouldn't be @include'd by gdb.texinfo and be part of the manual? Right now, "set annotate" is not documented at all, and annotate.texi seems to be just what the doctor ordered... And while at that, NEWS seems to be in the need of some work, it doesn't mention many of the new features that already are in the CVS tree. I would like at least to mention the improvements in the DJGPP version. >From kevinb@cygnus.com Sat Apr 01 00:00:00 2000 From: Kevin Buettner To: Franz Sirl , gdb@sourceware.cygnus.com Subject: Re: Patches for GNU/Linux PPC native now in CVS Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <1000224095244.ZM13976@ocotillo.lan> References: <1000222025201.ZM9805@ocotillo.lan> <00022300073001.01275@enzo.bigblue.local> X-SW-Source: 2000-q1/msg00395.html Content-length: 890 On Feb 22, 11:09pm, Franz Sirl wrote: > >I invite those of you who have Linux/PPC machines to try out these > >changes and let me know how they work. Also, please let me know about > >any problems that you find. > > I've just uploaded an RPM with the current CVS source to > ftp://devel.linuxppc.org/users/fsirl/ so people can easily test it. Thanks. [...] > A quick test of gdb looked very promising, I already installed it as the > default gdb on our build system. What about "info float"? Are you going to > tackle this yourself later or do you want to leave the implementation to > somebody else? If someone else is willing to do the implementation for "info float", I'm willing to integrate the patches. (I rarely have need for "info float", so it may be better if someone else did the implementation.) OTOH, if no one sends me patches, I'll try to get to it eventually. Kevin >From hjl@lucon.org Sat Apr 01 00:00:00 2000 From: "H . J . Lu" To: "J.T. Conklin" Cc: Stan Shebs , gdb-patches@sourceware.cygnus.com, GDB Subject: Re: A patch for gnu-regex Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000307162127.D485@lucon.org> References: <20000307134103.A20533@valinux.com> <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00576.html Content-length: 534 On Tue, Mar 07, 2000 at 04:18:23PM -0800, J.T. Conklin wrote: > >>>>> "hjl" == H J Lu writes: > > hjl> 2000-03-07 H.J. Lu > hjl> > hjl> * gdb-regex.h: New. Include for glibc 2 and include > hjl> "gnu-regex.h" otherwise. > > If we follow the naming convention we have been using, gdb-regex.h There are gdb-events.c gdb-events.h gdb-events.sh gdb-regex.h gdb-stabs.h. > should be gdb_regex.h. Either way is fine with me. All I want is regex in glibc 2 :-). Any objections? H.J. >From scottb@netwinder.org Sat Apr 01 00:00:00 2000 From: Scott Bambrough To: GDB Mailing List Subject: GDB configure problem in the new repository... Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A41C50.F4E522DD@netwinder.org> X-SW-Source: 2000-q1/msg00222.html Content-length: 1141 Hi, I checked out a GDB tree on a clean system from the new repository using: cvs -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src co gdb and attempted to configure using the following directory structure: cvstree/src cvstree/gdb-build cd gdb-build ../src/configure --prefix=/usr I get the following error: checking for Tcl configuration... found /usr/lib/tclConfig.sh checking for Tk configuration... found /usr/lib/tkConfig.sh checking for Tcl private headers. dir=unix... checking for tclInt.h... no configure: error: Can't find Tcl private headers I checked out the entire tree under src on another machine the other day using the same setup and I could configure and build with the following results for a native armv4l-unknown-linux-gnu target on a NetWinder. === gdb Summary === # of expected passes 6296 # of unexpected failures 56 # of unexpected successes 1 # of expected failures 195 # of unresolved testcases 2 # of untested testcases 5 Scott -- Scott Bambrough - Software Engineer REBEL.COM http://www.rebel.com NetWinder http://www.netwinder.org >From hjl@valinux.com Sat Apr 01 00:00:00 2000 From: "H . J . Lu" To: Kevin Buettner Cc: GDB Subject: Re: Does today's gdb compile on Linux? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000118104731.B7970@valinux.com> References: <20000118100532.A7871@valinux.com> <1000118184306.ZM1103@ocotillo.lan> X-SW-Source: 2000-q1/msg00041.html Content-length: 1621 On Tue, Jan 18, 2000 at 11:43:06AM -0700, Kevin Buettner wrote: > On Jan 18, 10:05am, H . J . Lu wrote: > > > I cannot get today's gdb in CVS to compile on Linux/ia32. It failed on > > i386-linux-nat.c: > > > > /work/gnu/import/gdb/gdb/i386-linux-nat.c: In function `supply_fpregset': > > /work/gnu/import/gdb/gdb/i386-linux-nat.c:215: request for member `st_space' in > > something not a structure or union > > /work/gnu/import/gdb/gdb/i386-linux-nat.c:217: request for member `cwd' in > > something not a structure or union > > /work/gnu/import/gdb/gdb/i386-linux-nat.c:218: request for member `swd' in > > something not a structure or union > > /work/gnu/import/gdb/gdb/i386-linux-nat.c:219: request for member `twd' in > > something not a structure or union > > /work/gnu/import/gdb/gdb/i386-linux-nat.c:220: request for member `fip' in > > > > Any ideas? > > It looks to me like HAVE_PTRACE_GETXFPREGS is getting defined in config.h > when it shouldn't be. I don't think so. # grep HAVE_PTRACE_GETXFPREGS config.h /* #undef HAVE_PTRACE_GETXFPREGS */ > > The following comment may shed some light... > > /* PTRACE_GETXFPREGS is a Cygnus invention, since we wrote our own > Linux kernel patch for SSE support. That patch may or may not > actually make it into the official distribution. If you find that > years have gone by since this code was added, and Linux isn't using > PTRACE_GETXFPREGS, that means that our patch didn't make it, and > you can delete this code. */ > > Do you have PTRACE_GETXFPREGS defined in your system header files > somewhere? > No. -- H.J. Lu (hjl@gnu.org) >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Pierre Muller Cc: gdb@sourceware.cygnus.com Subject: Re: Updated MAINTAINERS file - work in progress Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A4FB7F.3B87A00F@cygnus.com> References: <200002111033.LAA29442@cerbere.u-strasbg.fr> X-SW-Source: 2000-q1/msg00241.html Content-length: 423 Pierre Muller wrote: > > At 21:33 10/02/00 -0800, you wrote: > >> Andrew Cagney ac131313@cygnus.com? > >> Stan Shebs shebs@cygnus.com? > > Wouldn't it be much more logical to have aliases here ? > > Andrew.Cagney@sourceware.cygnus.com > or even better We could. Unfortunatly it would introduce a dependence on the fsf.org admin and they already have enough to do. Andrew >From Stephane.Bihan@arccores.com Sat Apr 01 00:00:00 2000 From: Stephane.Bihan@arccores.com To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.) Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: X-SW-Source: 2000-q1/msg00710.html Content-length: 2269 > > Stephane> I also use the breakpoint structure as an extern variable. I > Stephane> needed it to implement the set_hw_breakpoint routine for the > Stephane> remote protocol. I think it's not the nicer way to do but > Stephane> .... > > Can you explain? I don't see any use of struct breakpoint in the > current arc-tdep.c, nor do I see a set_hw_breakpoint function? The version at FSF is a very old version out of date. I am currently extending gdb for ARC to support user extensions. > > >> Since you say you can remove the single step code, I assume that the > >> ISS target and remote protocol agents can perform the single step by > >> themselves? If so, it would be advantageous to disable GDB's single > >> step support. GDB would then issue a single "step" command instead of > >> "insert breakpoint(s)", "continue", and "remove breakpoint(s)". The > >> latency of a step should be greatly improved. > > Stephane> I will implement this for the remote target only since the > Stephane> hardware supports single-stepping. I'm not sure if this > Stephane> feasible in the ISS - Yuri? > > Stephane> If not feasible I won't disable the GDB's single step > Stephane> support (thus enabling a call to single_step()) but I will > Stephane> implement a single_step call to gdbstub in remote_resume(). > > If your ISS target cannot support single step, but the remote protocol > can, perhaps the best thing is to make software single step a target > specific option. By creating a target specific command? The single step mechanism is a not a step-over-calls mechanism. > > I don't think that the arc is the only processor that would benefit > from such a change. For example, the sparclet ROM monitor supports a > single step command, but I do not know if it is ever issued because > the SPARC target uses software single step. Perhaps it inserts the > trap instructions needed for single step and issues the monitor step > command? > > I do not think it's possible for any change to remote_resume() to be > the right solution. > You're right, I've tried and if does not work. Thanks for your explanations anyway. Stephane. ---------------------------------------------------------------- Stephane Bihan ARC Cores Ltd http://www.arccores.com