From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: William Gatliff Cc: jtc@redback.com, Stan Shebs , gdb@sourceware.cygnus.com Subject: Re: What's with all the Cisco stuff? Date: Mon, 16 Aug 1999 18:49:00 -0000 Message-id: <37B8BF2B.8C634EF7@cygnus.com> References: <199908132208.PAA19753@andros.cygnus.com> <5mn1vriieb.fsf@jtc.redbacknetworks.com> <37B87B49.268721B5@haulpak.com> X-SW-Source: 1999-q3/msg00183.html William Gatliff wrote: > > > Stan> eCos and other folks observed that this was probably too > > Stan> heavyweight to impose on every RTOS, although it would make > > Stan> sense for the larger OSes. > > > > Even though I walked through the above thought experiment, I'm still > > not convinced that direct access to kernel data structures with GDB > > scripts is not superior. > > I agree completely-- keeping a "thin" stub is definitely the way to go. There isn't a correct solution. There are two solutions each applicable to a their own problem domain. GDB needs to be able to accomodate both of them. Think of the problem in terms of layers. It should be possible to implement the extract kernel info layer on either the host or the target. enjoy, Andrew >From shebs@cygnus.com Mon Aug 16 19:00:00 1999 From: Stan Shebs To: gatliff@haulpak.com Cc: jtc@redback.com, gdb@sourceware.cygnus.com Subject: Re: What's with all the Cisco stuff? Date: Mon, 16 Aug 1999 19:00:00 -0000 Message-id: <199908170200.TAA03328@andros.cygnus.com> References: <37B87B49.268721B5@haulpak.com> X-SW-Source: 1999-q3/msg00184.html Content-length: 1208 Date: Mon, 16 Aug 1999 15:57:45 -0500 From: William Gatliff > Stan> eCos and other folks observed that this was probably too > Stan> heavyweight to impose on every RTOS, although it would make > Stan> sense for the larger OSes. > > Even though I walked through the above thought experiment, I'm still > not convinced that direct access to kernel data structures with GDB > scripts is not superior. I agree completely-- keeping a "thin" stub is definitely the way to go. Absolutely, if it's possible. In retrospect, what I'm after may be something less related to what you guys are talking about than I thought... If I'm trying to make gdb "aware" of an RTOS like uC/OS or eCos, for which I have sources, then the kernel data structures should exist as symbols, so I should be able to peek/poke at them with regular gdb functionality when the target stops. Sources are convenient, although of course they're not available for many OSes that we want to support. Also, you could run into a situation where the OS sources changed slightly, so symbol-based scripts fail, while a protocol-based design would continue to work. Stan >From jimb@cygnus.com Mon Aug 16 22:24:00 1999 From: Jim Blandy To: Bill Mann Cc: Jim Blandy , Kevin Buettner , gdb@sourceware.cygnus.com Subject: Re: Temporary breakpoints Date: Mon, 16 Aug 1999 22:24:00 -0000 Message-id: References: <11> <1999> <19:52:45> <-0700(PDT)> <199908120252.TAA25463@elmo.cygnus.com> <4.1.19990816090334.00c4fd70@mailhost.avici.com> X-SW-Source: 1999-q3/msg00185.html Content-length: 1159 > >GDB does not report a breakpoint hit if it occurs exactly when GDB > >would have stopped stepping anyway. So, if you set a breakpoint on > >the first instruction of a line, and "step" to it, GDB won't report a > >hit, because it would have stopped there anyway. If you set a > >breakpoint on an instruction in the middle of the line, GDB will > >report it, because you've stopped in an unusual place. But if you > >stepi, then GDB will never report a breakpoint hit. > > But I think that's not the way it should work. If I set a breakpoint, then > step over it, I want the breakpoint to be hit. I want it to print what it > would normally print, or count if it's a multiple proceed, or execute > special commands if they are defined. I see a breakpoint as a temporary > patch to my program, and I want single step to honor that patch (as > a unit). I think it's a matter of opinion. The behavior you describe is the behavior I'd want if I were writing code that used it (which is consistent with your view of a breakpoint as a patch), but not what I want as a human being trying to watch my program run (I already knew I was going to stop there). >From msnyder@cygnus.com Tue Aug 17 08:00:00 1999 From: "Michael Snyder" To: gdb@sourceware.cygnus.com Subject: Re: Mips 64bit and GDB Date: Tue, 17 Aug 1999 08:00:00 -0000 Message-id: <7pbt60$fp6$1@cronkite.cygnus.com> References: <19990817113956.A18702@garfield.inodes.org> X-SW-Source: 1999-q3/msg00186.html Content-length: 644 John Ferlito wrote in message < 19990817113956.A18702@garfield.inodes.org >... > > Does anyone know if it's possible to debug executables created with > the native IRIX 64 bit compiler using GDB. > > Or alternatively does anyone know if a copy of the gcc tool-chain > exists anywhere for 64 bit MIPS that will actually compile stuff with > debugging symbols. Unfortunately I'm not up on my Irix versions, but GDB's set of known target architectures does include a "mips64", and it certainly supports many different flavors of Irix. Are you in a position to just try it and see? Michael