From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: What's with all the Cisco stuff? Date: Thu, 12 Aug 1999 18:39:00 -0000 Message-id: <37B376F2.A5739F43@cygnus.com> References: <5md7wv2aif.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q3/msg00159.html "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 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 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 To: Stan Shebs 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