Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: William Gatliff <gatliff@haulpak.com>
Cc: jtc@redback.com, Stan Shebs <shebs@cygnus.com>,
	gdb@sourceware.cygnus.com
Subject: Re: What's with all the Cisco stuff?
Date: Mon, 16 Aug 1999 18:49:00 -0000	[thread overview]
Message-ID: <37B8BF2B.8C634EF7@cygnus.com> (raw)
In-Reply-To: <37B87B49.268721B5@haulpak.com>

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 <shebs@cygnus.com>
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 <gatliff@haulpak.com>

   > 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 <jimb@cygnus.com>
To: Bill Mann <wmann@avici.com>
Cc: Jim Blandy <jimb@cygnus.com>, Kevin Buettner <kevinb@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: Temporary breakpoints
Date: Mon, 16 Aug 1999 22:24:00 -0000
Message-id: <np7lmvt1xn.fsf@zwingli.cygnus.com>
References: <Kevin> <Buettner's> <message> <of> <Wed,> <11> <Aug> <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" <msnyder@cygnus.com>
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




  parent reply	other threads:[~1999-08-16 18:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <37B419FD.C9748ABE@haulpak.com>
1999-08-13 15:08 ` Stan Shebs
     [not found]   ` <5mn1vriieb.fsf@jtc.redbacknetworks.com>
     [not found]     ` <37B87B49.268721B5@haulpak.com>
1999-08-16 18:49       ` Andrew Cagney [this message]
     [not found] <199908170140.SAA03308@andros.cygnus.com>
1999-08-17 12:10 ` J.T. Conklin
     [not found] <5md7wv2aif.fsf@jtc.redbacknetworks.com>
1999-08-12 18:39 ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=37B8BF2B.8C634EF7@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=gatliff@haulpak.com \
    --cc=gdb@sourceware.cygnus.com \
    --cc=jtc@redback.com \
    --cc=shebs@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox