Re: What's with all the Cisco stuff?

Re: What's with all the Cisco stuff?

[Stan Shebs]

   Date: Fri, 13 Aug 1999 08:13:33 -0500
   From: William Gatliff <gatliff@haulpak.com>

   > I would ecstatic with more interest and input here.  "RTOS support" is
   > an area where GDB gets hammered relative to its competition, and
   > display of kernel objects is a specific feature that gets comes up
   > frequently.

   On the embedded side, could RTOS support be made a stub issue, instead of a
   gdb issue?  As an embedded developer, I find it much easier to add/modify a
   stub than to muck around with the internals of gdb itself.

   If there were a standard set of RDP messages that could be used to deliver
   OS information from a stub back to gdb, then I would be happy to add stub
   support for my own RTOS, whatever that happens to be, using the RTOS's
   native calls.

That was kicked around a bit in our internal (ahem :-) ) discussion.
Basically you ask the RTOS "what kinda objects you got?", get back a list
of types, then ask "how should type X be displayed?" and get back
something like a printf format string or maybe even a bit of XML,
then GDB follows instructions when getting the objects' data and
displaying it.

eCos and other folks observed that this was probably too heavyweight
to impose on every RTOS, although it would make sense for the larger
OSes.  Also, you still have the dumpfile problem that JT alluded to,
where you don't necessarily have a live target to run a stub.  So
while it would be preferable to put OS-specific bits on the target
side, the design needs to accommodate the possibility that all the
IQ is living on the host somewhere.

								Stan
From jtc@redback.com Fri Aug 13 16:49:00 1999
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: Code in can_use_hardware_watchpoint()
Date: Fri, 13 Aug 1999 16:49:00 -0000
Message-id: <5mu2q3jl6i.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q3/msg00168.html
Content-length: 1164

I believe the enclosed code from can_use_hardware_watchpoint() has a
problem, but I'm unsure of the proper fix.  

The problem is that a expression containing a register variable will
not cause this function to fail (return 0).  This seems to result in
GDB forging ahead and placing a hardware watchpoint at a random
address for the register variable.  An example of this is something
like 'watch mem[reg] != 0'.

  /* Make sure all the intermediate values are in memory.  Also make sure
     we found at least one memory expression.  Guards against watch 0x12345,
     which is meaningless, but could cause errors if one tries to insert a 
     hardware watchpoint for the constant expression.  */
  for (; v; v = v->next)
    {
      if (v->lval == lval_memory)
	{
	  if (TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT (TYPE_LENGTH (VALUE_TYPE (v))))
	    found_memory_cnt++;
	}
      else if (v->lval != not_lval && v->modifiable == 0)
	return 0;
    }

One solution is to add an:

      else if (v->lval == lval_register)
        return 0;

But I'm wondering if instead the v->modifiable == 0 should be == 1
instead.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From eliz@gnu.org Sun Aug 15 05:34:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: gdb@sourceware.cygnus.com
Cc: jtc@redback.com (J.T. Conklin)
Subject: Re: Code in can_use_hardware_watchpoint()
Date: Sun, 15 Aug 1999 05:34:00 -0000
Message-id: <199908151234.IAA14013@mescaline.gnu.org>
References: <5mu2q3jl6i.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q3/msg00169.html
Content-length: 730

  From: jtc@redback.com (J.T. Conklin) 
  Date: 13 Aug 1999 16:49:25 -0700

> I believe the enclosed code from can_use_hardware_watchpoint() has a
> problem, but I'm unsure of the proper fix.

As long as we are talking about this function, here's another
question: shouldn't the loop below return zero as soon as the first
value is found on the value chain that is NOT okay to watch (as the
macro TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT says)?

  for (; v; v = v->next)
    {
      if (v->lval == lval_memory)
        {
          if (TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT (TYPE_LENGTH (VALUE_TYPE (v))))
            found_memory_cnt++;
        }
      else if (v->lval != not_lval && v->modifiable == 0)
        return 0;
    }
From jimb@cygnus.com Sun Aug 15 23:28:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: What's with all the Cisco stuff?
Date: Sun, 15 Aug 1999 23:28:00 -0000
Message-id: <np907cutnd.fsf@zwingli.cygnus.com>
References: <199908132135.OAA19734@andros.cygnus.com>
X-SW-Source: 1999-q3/msg00170.html
Content-length: 1974

As long as we're talking about philosophy...

I agree very much with Stan that GDB should be a bag of tools that
just works, without getting fussy about exactly which features you
configured in, and which you left out.  I come closest to throwing a
tantrum when I have to struggle with my debugger while debugging
something else, under a deadline.  And I'm on Cygnus's GDB team ---
what's it like for someone else?

However, I am concerned about the approach described here, which I
suspect is really at the heart of JT's concerns:

    Ultimately I'd like to see more modularity for system-specific
    bits, but we're not there yet, and I don't want to see users
    switching to other debuggers because we're waiting for somebody to
    write more elegant code.

I read this as, "We will integrate features people want even if they
are non-modular.  Doing them in a modular way takes too much time.
We'll get around to it eventually."

I don't think this approach is long-term sustainable.  We don't need
modularity because it's beautiful --- we need modularity because,
although we are under deadlines now, we will also be under deadlines a
year from now.  Or two years from now.

Beauty and modularity are different.  GDB's processor architecture
interface (pre multi-arch) is modular, but not beautiful.  We support,
what, twenty different processors?  But clearly, you can work on GDB
without knowing them all.  So that's a successful structuring.

The problem with the Cisco changes is that they're just sort of mixed
in with the remote stuff (among other things), which ought to be
staying really simple.  When I want to understand how remote.c works,
I need to read the Cisco stuff just to reassure myself that it isn't
relevant.  Is everyone prepared to jump into remote.c for a contract,
now that it's grown from 3500 lines (June 6) to 5240 lines (Aug 5)?

I don't have specific ideas for how to fix this, though.  But I do
think JT's identified a real problem.
From ac131313@cygnus.com Sun Aug 15 23:47:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Stan Shebs <shebs@cygnus.com>, jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: What's with all the Cisco stuff?
Date: Sun, 15 Aug 1999 23:47:00 -0000
Message-id: <37B7B399.714F00DC@cygnus.com>
References: <199908132135.OAA19734@andros.cygnus.com> <np907cutnd.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00171.html
Content-length: 770

Jim Blandy wrote:

> The problem with the Cisco changes is that they're just sort of mixed
> in with the remote stuff (among other things), which ought to be
> staying really simple.  When I want to understand how remote.c works,
> I need to read the Cisco stuff just to reassure myself that it isn't
> relevant.  Is everyone prepared to jump into remote.c for a contract,
> now that it's grown from 3500 lines (June 6) to 5240 lines (Aug 5)?

Just to expand on this a little.  Two things caused remote.c to expand. 
The more important one was that I recommending to Elena that a patch
adding the targets ``async'' and ``extended-async'' be committed.

In the future those targets will be absorbed into more familar
``remote'' and ``extended-remote''.

	enjoy,
		Andrew
From jimb@cygnus.com Sun Aug 15 23:50:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Temporary breakpoints
Date: Sun, 15 Aug 1999 23:50:00 -0000
Message-id: <np7lmwusmm.fsf@zwingli.cygnus.com>
References: <199908120252.TAA25463@elmo.cygnus.com>
X-SW-Source: 1999-q3/msg00172.html
Content-length: 1484

> I have a question regarding temporary breakpoints...
> 
> Under what circumstances should a temporary breakpoint be deleted?

It should be deleted under the same circumstances in which GDB tells
the user it has been hit.  A temporary breakpoint is a user-visible
construct (unlike many breakpoints in GDB), so its behavior must be
consistent from the user's point of view.

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.

It's worth noting that a breakpoint's behavior depends on its intended
use.  Breakpoints which GDB uses to implement some internal feature
should behave differently from user-level breakpoints.  For example,
the breakpoint which GDB uses to tell when a new shared library has
been loaded should be considered "hit" even if you reach it via stepi,
or even if the user has set another breakpoint on top of it ---
otherwise, GDB will miss the event it was waiting for.

This is what that hairy, worthless table in bpstat_what is all about.
Note that the whole table could be replaced by a call to `max' and a
little logic, if someone wants to take the time.
From jimb@cygnus.com Mon Aug 16 00:04:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Code in can_use_hardware_watchpoint()
Date: Mon, 16 Aug 1999 00:04:00 -0000
Message-id: <np672gury4.fsf@zwingli.cygnus.com>
References: <5mu2q3jl6i.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q3/msg00173.html
Content-length: 640

I'm not really familiar with this code, but:

> One solution is to add an:
> 
>       else if (v->lval == lval_register)
>         return 0;

I think this is the right thing.

The value chain is supposed to be a list of all the values generated
while evaluating the watchpoint's expression.  (What if someone else
generates a value in the mean time?  Don't you think it's a bad idea
to draft a list intended for storage management into use in expression
analysis?  Bleah.)  If you find anything on there that could change,
but can't be watched, you should return zero.

But the fix seems so obvious there must be something else going on...
From law@cygnus.com Mon Aug 16 00:40:00 1999
From: "Jeffrey A. Law" <law@cygnus.com>
To: jimb@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Code in can_use_hardware_watchpoint()
Date: Mon, 16 Aug 1999 00:40:00 -0000
Message-id: <199908160740.AAA18545@rtl.cygnus.com>
References: <5mu2q3jl6i.fsf@jtc.redbacknetworks.com> <np672gury4.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00174.html
Content-length: 1483

In article < np672gury4.fsf@zwingli.cygnus.com > you write:
>I'm not really familiar with this code, but:
>
>> One solution is to add an:
>> 
>>       else if (v->lval == lval_register)
>>         return 0;
>
>I think this is the right thing.
>
>The value chain is supposed to be a list of all the values generated
>while evaluating the watchpoint's expression.  (What if someone else
>generates a value in the mean time?  Don't you think it's a bad idea
>to draft a list intended for storage management into use in expression
>analysis?  Bleah.)  If you find anything on there that could change,
>but can't be watched, you should return zero.
I agree with Jim (and I am somewhat familiar with the code, though most
of the details have become fuzzy over the years).

Basically we have to build a list of all the expressions/values which
are required to evaluate a watchpoint.  If anything on that list of
values can not be watched with a hardware watchpoint, then we do not
allow hardware watchpoints to be used.

>But the fix seems so obvious there must be something else going on...
I don't think so.  I think it's just a case we didn't properly think
through.

If the only value on the chain was a reg, then we'd be OK because we would
not have found a memory location.  But if we try to watch p->q and P is in
a reg, then we'd lose.

At one time that code may have done an "else return 0;", but that may have
been kicking out too many things which it should have accepted.

jeff
From wmann@avici.com Mon Aug 16 06:17:00 1999
From: Bill Mann <wmann@avici.com>
To: Jim Blandy <jimb@cygnus.com>, Kevin Buettner <kevinb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Temporary breakpoints
Date: Mon, 16 Aug 1999 06:17:00 -0000
Message-id: <4.1.19990816090334.00c4fd70@mailhost.avici.com>
References: <Kevin> <Buettner's> <message> <of> <Wed,> <11> <Aug> <1999> <19:52:45> <-0700> <(PDT)> <199908120252.TAA25463@elmo.cygnus.com> <np7lmwusmm.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q3/msg00175.html
Content-length: 2222

At 01:49 AM 8/16/99 -0500, Jim Blandy wrote:
>
>> I have a question regarding temporary breakpoints...
>> 
>> Under what circumstances should a temporary breakpoint be deleted?
>
>It should be deleted under the same circumstances in which GDB tells
>the user it has been hit.  A temporary breakpoint is a user-visible
>construct (unlike many breakpoints in GDB), so its behavior must be
>consistent from the user's point of view.

Right!

>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).

>It's worth noting that a breakpoint's behavior depends on its intended
>use.  Breakpoints which GDB uses to implement some internal feature
>should behave differently from user-level breakpoints.  For example,
>the breakpoint which GDB uses to tell when a new shared library has
>been loaded should be considered "hit" even if you reach it via stepi,
>or even if the user has set another breakpoint on top of it ---
>otherwise, GDB will miss the event it was waiting for.

But what's different about internal breakpoints?  All breakpoints should
work like this.  If there are several breakpoints at the same location,
they should all be executed, one after the other, but only return
interactive control to the user if one or more of them don't 'continue'.

>This is what that hairy, worthless table in bpstat_what is all about.
>Note that the whole table could be replaced by a call to `max' and a
>little logic, if someone wants to take the time.

Re: What's with all the Cisco stuff?

[Andrew Cagney]

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

Re: What's with all the Cisco stuff?

[J.T. Conklin]

>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:
jtc> I've thought about this a bit, and it seems the best model to use
jtc> is something like SNMP.  But instead of a pre-defined MIB that is
jtc> known by both the debug agent on the target and GDB, the MIB is
jtc> downloaded from the target.  There should probably be traps so
jtc> the debug agent can tell GDB that new MIBs are present or old
jtc> ones have been removed if the kernel has loadable kernel modules
jtc> or the like.

Stan> Going by your description, this seems very heavyweight, only
Stan> really appropriate for Unix-sized OSes.  But I'm not that
Stan> familiar with SNMP; what should I look at to educate myself?

SNMPv1 is described in RFCs 1155, 1157, and 1213.  Although in this
case, a summary is probably more valuable than the specification. I
re-read Chapter 25 of Stevens' _TCP Illustrated, Volume I_ as I was
thinking about the similarities between SNMP and KOD.

I think it's fair to characterize SNMP as heavyweight implementation
of simple concepts.  And those concepts seem to fit the requirements
of a KOD system fairly well.

        * A mechanism for uniquely identifying objects.
       
        * A mechanism for describing the type of an object,
          constructing aggregate types out of simple types.

                SNMP's base types are INTEGER, OCTET STRING, Counter,
                Gauge, etc.  KOD would require types like unsigned 32
                bit integer, IEEE double precision float, etc.

        * A mechanism for constructing vector/tables from dynamic 
          data structures (lists, trees, etc.)

        * A mechanism for fetching objects

        * A mechanism for representing everything on the wire.

Unlike SNMP, where the MIB definition is known by both the agent and
the network management station, KOD has a additional requirement of:

        * A mechanism for obtaining the list of kernel objects from
          the target.

jtc> Even though I walked through the above thought experiment,
jtc> I'm still not convinced that direct access to kernel data
jtc> structures with GDB scripts is not superior.

Stan> You're assuming that direct access is possible though.  While
Stan> some, like VxWorks, give you full access to things like task
Stan> state, others, like QNX, don't seem to keep kernel data in a
Stan> place where you can get to it.

I don't think I'm making any such assumption, but I guess it depends
on how you define 'kernel'.  In systems like QNX, a lot of what might
be considered kernel services are implemented by user level processes.
In my definition of kernel, only the microkernel itself is the kernel
and only it has kernel objects.  The rest is application space, and
can be debugged like any other multi-process application.  If the
definition of kernel is extended to contain the process manager and
various resource managers/device drivers, I can see the problems as
the debug agent has to cross process boundries.

Stan> It's also easy to imagine an RTOS that got stopped right in the
Stan> middle of updating a kernel object; wouldn't you rather have the
Stan> RTOS report "invalid, please step to <x>" instead of being
Stan> misled by pointers and references that don't connect right?

This is going to be hard to handle in any case.  I find it hard to
believe that any RTOS is going to make concessions for the case where
the kernel is interrupted while objects are being updated.  How is the
debug agent going to know this is true, and what value is it going to
substitute?

Stan> Yes, which is why a display-only ability is a good intermediate
Stan> step.  GDB often doesn't make values out of the data it
Stan> displays, for instance the output of "x" is just output, you
Stan> don't get an array of values.  But I think that everybody still
Stan> finds "x" to be a useful command.

Yes, but there is alternatives to "x" when you need to manipulate a
memory value in a GDB expression.  Casting an address to a type and
dereferencing it may be a bit ugly, but it works.  Likewise for info
registers it outputs a pretty list of registers, but you can use $pc,
$sp, etc. convienence variables in expressions.

A kernel object system without the ability to use those values in
expressions seems vary limited to me.  Perhaps this is just my bias,
scripting is an integral part of the debugging experience/process to
me.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Tue Aug 17 12:26:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Michael Snyder <msnyder@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: [Fwd: TARGET_WAITKIND_THREAD_[CREATION || DELETION]]
Date: Tue, 17 Aug 1999 12:26:00 -0000
Message-id: <5mso5igqfd.fsf@jtc.redbacknetworks.com>
References: <37B8A106.3368@cygnus.com>
X-SW-Source: 1999-q3/msg00188.html
Content-length: 1323

>>>>> "Michael" == Michael Snyder <msnyder@cygnus.com> writes:
Michael> I want to add two new entries to the list of reasons why
Michael> target_wait may return (ie. why the target may have stopped).
Michael> 	THREAD_CREATION, and 
Micheal>        THREAD_DELETION.
Micheal>
Michael> These will allow GDB to perform any housekeeping it needs to
Michael> do to manage threads. 

Sounds good.

Longer term, it might be useful to shape the breakpoint/watchpoint/
catchpoint/signal mechanism into a more general 'eventpoint' scheme,
where all sorts of events can be managed.  Ideally, it would be
relatively easy to add events on a per-target basis.

Micheal> For instance, GDB may want to remove a step_resume breakpoint
Micheal> that was in use by the thread that has exited.

This is important.  Many systems use the address of the thread control
block (whatever it may be called) as the thread id.  Also new TCBs are
often allocated from a free pool of TCBs from threads that have exited.
In such systems, it is quite common for different threads to have the
same IDs. If a breakpoint is set in a thread that exits, unless it is 
removed at that time it will also be present in the new thread.

Michael> Comments?

Glad to see such discussion on the public list :-)

        --jtc
        
-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Tue Aug 17 23:50:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Code in can_use_hardware_watchpoint()
Date: Tue, 17 Aug 1999 23:50:00 -0000
Message-id: <5mk8qt60se.fsf@jtc.redbacknetworks.com>
References: <5mu2q3jl6i.fsf@jtc.redbacknetworks.com> <199908151234.IAA14013@mescaline.gnu.org>
X-SW-Source: 1999-q3/msg00189.html
Content-length: 1147

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
jtc> I believe the enclosed code from can_use_hardware_watchpoint() has
jtc> a problem, but I'm unsure of the proper fix.

Eli> As long as we are talking about this function, here's another
Eli> question: shouldn't the loop below return zero as soon as the
Eli> first value is found on the value chain that is NOT okay to watch
Eli> (as the macro TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT says)?

I'm inclined to agree.  

If I understand things, if an expression contains a memory variable
that can be watched by the target's debug registers and another that
cannot, can_use_hardware_watchpoint() will return a value, which GDB
will interpret as the target can implement the watchpoint expression
in hardware.

Eli>   for (; v; v = v->next)
Eli>     {
Eli>       if (v->lval == lval_memory)
Eli>         {
Eli>           if (TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT
Eli>           (TYPE_LENGTH (VALUE_TYPE (v))))
Eli>             found_memory_cnt++;
Eli>         }
Eli>       else if (v->lval != not_lval && v->modifiable == 0)
Eli>         return 0;
Eli>     }

-- 
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Wed Aug 18 02:06:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: binutils@sourceware.cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Default architecture according --target=...configury?
Date: Wed, 18 Aug 1999 02:06:00 -0000
Message-id: <37BA7767.55040774@cygnus.com>
X-SW-Source: 1999-q3/msg00190.html
Content-length: 992

Hello,

Is it possible to reliably determine the default architecture (struct
bfd_arch_info) as selected by the configuration option --target=....
(even when --enable-targets was specified)?

I suspect not but would like to double check.

My guess at the change required is for archures.c:

  static const bfd_arch_info_type * const bfd_archures_list[] =
  {
  #ifdef SELECT_ARCHITECTURES
    SELECT_ARCHITECTURES,
  #else
    &bfd_a29k_arch,

to be modified to be more like targets.c vs:

  const bfd_target * const bfd_target_vector[] = {

  #ifdef SELECT_VECS

	  SELECT_VECS,

  #else /* not SELECT_VECS */

  #ifdef DEFAULT_VECTOR
	  &DEFAULT_VECTOR,
  #endif

(Add DEFAULT_ARCHITECTURE_VECTOR say).

The function bfd_lookup_arch() could then be modified to detect a user
asking for a default architecture (arch == 0 (bfd_arch_unknown)?).

Comments?

	Andrew

PS: Why?  I'd like GDB to make a better guess at a default
architecture.  bfd_default_arch_struct just isn't very interesting.
From eliz@gnu.org Wed Aug 18 07:41:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb@sourceware.cygnus.com, DJ Delorie <dj@delorie.com>
Subject: Re: Single-stepping through INT nn instructions
Date: Wed, 18 Aug 1999 07:41:00 -0000
Message-id: <199908181440.KAA04508@mescaline.gnu.org>
References: <np1ze644sj.fsf@zwingli.cygnus.com> <199907150913.FAA01508@indy.delorie.com>
X-SW-Source: 1999-q3/msg00191.html
Content-length: 1518

> > > So you're trying to step *into* an int, not over it, right?
> >
> > I meant this: suppose the debuggee is stopped right in front of the
> > INT nn instruction.  Now I want to do a "stepi" in GDB.
> 
> Hmm.  The system call seems to happen on the instruction *after* the
> int, so I think I have no idea what's going on here.  I don't think
> GDB can really "simulate" an `int' in this context.  Let me know what
> you come up with.

I believe that what you see on Linux proves that `ptrace' somehow
handles this behind the scenes:

> (gdb)
> 0x804caa2 in __write ()
> 1: x/i $eip  0x804caa2 <__write+18>:    int    $0x80
> (gdb)
> 0x804caa4 in __write ()

Here, single-step resumed right after the Int 80h call.  Doesn't this
look like some kind of magic?
 
In the DJGPP version, it doesn't work so smoothly.  However, the
problem seems to be that the Trap Flag is set when INT nn is hit.

DJ, is it correct that having TF set when INT nn is issued is a Bad
Idea?  I tested this only with Int 31h, the DPMI interrupt, but I
vaguely recall that it's a bad idea in general (e.g., __dpmi_int
clears it).

To see the problem, set a software watchpoint and then run the
debuggee through a line that calls printf: it will crash.

Jim, perhaps doing the above is not the same as repeated stepi, so
maybe you should try on Linux with software watchpoints, like I did.

I solved the problem in go32-nat.c by clearing TF and simulating it
with an INT 3 opcode inserted right after INT nn.  See the patches I
posted today.
From eliz@gnu.org Wed Aug 18 08:59:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: "J.T. Conklin" <jtc@redback.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Code in can_use_hardware_watchpoint()
Date: Wed, 18 Aug 1999 08:59:00 -0000
Message-id: <199908181558.LAA08688@mescaline.gnu.org>
X-SW-Source: 1999-q3/msg00192.html
Content-length: 878

> If I understand things, if an expression contains a memory variable
> that can be watched by the target's debug registers and another that
> cannot, can_use_hardware_watchpoint() will return a value, which GDB
> will interpret as the target can implement the watchpoint expression
> in hardware.

Exactly.  And when the time comes to actually insert the watchpoint,
GDB complains that it cannot.

I posted today to gdb-patches a bunch of watchpoint-related patches.
One of them makes can_use_hardware_watchpoint return zero as soon as
it sees one value on the value chain that cannot be watched.  I also
introduced a new macro TARGET_REGION_OK_FOR_HW_WATCHPOINT which
accepts the address of the value to be watched as well as its size,
because the ability to watch large regions depends on the alignment of
their address (the number of required debug registers is different).
From dj@delorie.com Wed Aug 18 09:13:00 1999
From: DJ Delorie <dj@delorie.com>
To: eliz@gnu.org
Cc: jimb@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Single-stepping through INT nn instructions
Date: Wed, 18 Aug 1999 09:13:00 -0000
Message-id: <199908181611.MAA06952@envy.delorie.com>
References: <np1ze644sj.fsf@zwingli.cygnus.com> <199907150913.FAA01508@indy.delorie.com> <199908181440.KAA04508@mescaline.gnu.org>
X-SW-Source: 1999-q3/msg00193.html
Content-length: 1197

> Here, single-step resumed right after the Int 80h call.  Doesn't this
> look like some kind of magic?
>  
> In the DJGPP version, it doesn't work so smoothly.  However, the
> problem seems to be that the Trap Flag is set when INT nn is hit.
> 
> DJ, is it correct that having TF set when INT nn is issued is a Bad
> Idea?  I tested this only with Int 31h, the DPMI interrupt, but I
> vaguely recall that it's a bad idea in general (e.g., __dpmi_int
> clears it).

INT is special in that the handler can (and usually *should*) modify
the flags register before returning, such that (unlike a hardware
interrupt) state is not preserved 100%.  If the INT handler resets the
trap flag, single stepping will be disabled upon return.

Whether or not TF is preserved across INT is up to the handler, not
the function that invokes the INT opcode.  Since we have no control
over the handlers (esp for DPMI), I think using an INT3 opcode is a
reasonable workaround.

On a side note, I've noticed that thw win32 API's single-stepping
stuff has a similar problem, so I have to check and re-set TF during
other exceptions.  MS will also automagically not allow you to
single-step into a call to a system DLL.
From ian@zembu.com Wed Aug 18 10:29:00 1999
From: Ian Lance Taylor <ian@zembu.com>
To: ac131313@cygnus.com
Cc: binutils@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Default architecture according --target=...configury?
Date: Wed, 18 Aug 1999 10:29:00 -0000
Message-id: <19990818165833.7196.qmail@daffy.airs.com>
References: <37BA7767.55040774@cygnus.com>
X-SW-Source: 1999-q3/msg00194.html
Content-length: 1185

   Date: Wed, 18 Aug 1999 19:05:43 +1000
   From: Andrew Cagney <ac131313@cygnus.com>

   Is it possible to reliably determine the default architecture (struct
   bfd_arch_info) as selected by the configuration option --target=....
   (even when --enable-targets was specified)?

Well, speaking precisely, there is no default architecture.  There is
a default BFD target, and if an object file is recognized using that
format running bfd_check_format will set the architecture
appropriately.  For example, if the default BFD target is
elf32-bigmips, BFD can recognize a file using any of the 16
architectures listed in bfd/cpu-mips.c.

So it really depends upon what you mean by the default architecture.
For example, if you configure gas for mips4111-elf, then gas will by
default generate object files which use the mips4111 architecture.

   PS: Why?  I'd like GDB to make a better guess at a default
   architecture.  bfd_default_arch_struct just isn't very interesting.

If you explain further what you mean by this, perhaps we can think of
some way to make it work for you.  When does gdb want to know the
default architecture?  What is it going to do with the information?

Ian
From brendan@dgs.monash.edu.au Wed Aug 18 16:56:00 1999
From: Brendan Simon <brendan@dgs.monash.edu.au>
To: gdb <gdb@sourceware.cygnus.com>, "Insight (GDB GUI)" <insight@sourceware.cygnus.com>
Subject: GDB and Insight CVS repositories.
Date: Wed, 18 Aug 1999 16:56:00 -0000
Message-id: <37BB482C.B50ADCBC@dgs.monash.edu.au>
X-SW-Source: 1999-q3/msg00195.html
Content-length: 1008

I've heard that tGDB and Insight have seperate CVS repositories.  Is
this true ?

Since Insight has the full GDB source included, I can see
synchronisation problems between the repositories.  I believe (not 100%
sure) that stock standard GDB (without the GUI) can be built from the
Insight sources.  Is this true ?  If so, it makes sense to me that there
is only one master source repository for Insight and GDB.  Those that
don't want a GUI can build with something like "make all-gdb
install-gdb" and those who want the GUI can build with something like
"make all install" or "make all-insight install-insight".  It seems
logical to me and can't see why 2 repositories should exist.  Maybe this
is just an interim thing until Insight is officially released.

I guess the other option is to seperate the GUI sources from GDB
sources.  I'm not sure of the details of how this would be done but
believe it is possible.  Are there any technical reasons why this can't
or shouldn't be done.

Brendan Simon.

Re: What's with all the Cisco stuff?

[Andrew Cagney]

"J.T. Conklin" wrote:
> 
> What's the deal with all the Cisco-specific stuff ending up in GDB?

I'll ignore the politics :-)

At a technical level, the ``cisco-stuff'' highlights a limitation of the
current target vector - you can't build up a true target stack.  (To get
a knife out, here I'm not talking about that *(&!@)$(& strata tha
currently exists in GDB :-)

The CISCO code should be implemented as a sequence:

	o	open the target using generic ``remote.c''.

	o	create a new target that passes through most
		requests but every so often interseeds an
		operation with a cisco specific on.

Re-vamping that code, isn't trivial - I looked at it doing some fixes
for the the d10v target.  At the time I backed away.
At present the task sits in my input stack :-(

	Andrew
From tromey@cygnus.com Thu Aug 12 23:15:00 1999
From: Tom Tromey <tromey@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: What's with all the Cisco stuff?
Date: Thu, 12 Aug 1999 23:15:00 -0000
Message-id: <87g11ow75w.fsf@cygnus.com>
References: <199908122301.QAA03422@andros.cygnus.com>
X-SW-Source: 1999-q3/msg00160.html
Content-length: 1168

>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:

Stan> Alternatively, modules could be made dynamically loadable, and I
Stan> think that is the right long-term direction; everything still
Stan> works the same from the user point of view, and simplifies the
Stan> base debugger.  Indeed, Fernando tangled with this for kod, the
Stan> results indicating that getting dynamic loading right everywhere
Stan> is a nontrivial task.

FWIW, getting this right for most useful host systems is easy: use
`libltdl', which comes with libtool.  I decided not to do this for
kod-cisco.c because I lost interest and time.  If someone wants to
libtoolize kod-cisco.c and add the required code to kod.c (and ltdl to
the build infrastructure) I would be happy to provide pointers and
advice.

It would be nice if different parts of gdb could be dynamically
loaded.  For instance, I'd rather not have support for Modula-2, or
Scheme, or even Java (shock, horror) unless I was debugging an
executable that needed these bits.  (This presumes that the savings
are worth the effort.  I haven't looked to see whether this is so, and
I suspect they are not.)

Tom
From gatliff@haulpak.com Fri Aug 13 06:13:00 1999
From: William Gatliff <gatliff@haulpak.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: What's with all the Cisco stuff?
Date: Fri, 13 Aug 1999 06:13:00 -0000
Message-id: <37B419FD.C9748ABE@haulpak.com>
References: <199908122320.QAA04670@andros.cygnus.com>
X-SW-Source: 1999-q3/msg00161.html
Content-length: 918

Guys:

I'm not sure I understand all the debate on KOD, so I'll stick to the parts
I know...

> I would ecstatic with more interest and input here.  "RTOS support" is
> an area where GDB gets hammered relative to its competition, and
> display of kernel objects is a specific feature that gets comes up
> frequently.

On the embedded side, could RTOS support be made a stub issue, instead of a
gdb issue?  As an embedded developer, I find it much easier to add/modify a
stub than to muck around with the internals of gdb itself.

If there were a standard set of RDP messages that could be used to deliver
OS information from a stub back to gdb, then I would be happy to add stub
support for my own RTOS, whatever that happens to be, using the RTOS's
native calls.

Perhaps this approach could be extended for non-remote debugging, as well?

b.g.

--
William A. Gatliff
Senior Design Engineer
Komatsu Mining Systems