From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Stan Shebs Cc: gdb@sourceware.cygnus.com Subject: Re: What's with all the Cisco stuff? Date: Tue, 17 Aug 1999 12:10:00 -0000 Message-id: <5mzozqgr6o.fsf@jtc.redbacknetworks.com> References: <199908170140.SAA03308@andros.cygnus.com> X-SW-Source: 1999-q3/msg00187.html >>>>> "Stan" == Stan Shebs 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 " 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 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 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 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 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 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 To: Jim Blandy Cc: gdb@sourceware.cygnus.com, DJ Delorie 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: <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 To: "J.T. Conklin" 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 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: <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 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 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 To: gdb , "Insight (GDB GUI)" 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.