Re: What's with all the Cisco stuff?

[jtc@redback.com (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.