From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: gdb@sourceware.cygnus.com Subject: -Wmissing-prototypes ... Date: Sat, 27 Nov 1999 18:50:00 -0000 Message-id: <37E5E508.D56E054C@cygnus.com> X-SW-Source: 1999-q4/msg00332.html FYI, There is now a reasonable chance that GDB can be compiled with the -Wmissing-prototypes option. Thanks to JimI, JimB and Fernando and Elena for various specific cleanups. Andrew My current list is: --enable-build-warnings=-Werror\ ,-Wimplicit\ ,-Wreturn-type\ ,-Wcomment\ ,-Wtrigraphs\ ,-Wformat\ ,-Wparentheses\ ,-Wpointer-arith\ ,-Wmissing-prototypes\ ,-Woverloaded-virtual\ >From cgf@cygnus.com Sat Nov 27 18:50:00 1999 From: cgf@cygnus.com (Chris Faylor) To: gdb@sourceware.cygnus.com Subject: Re: Debugging Windows Namespace extension dll Date: Sat, 27 Nov 1999 18:50:00 -0000 Message-id: <7rpjdk$a2b$1@cronkite.cygnus.com> References: X-SW-Source: 1999-q4/msg00333.html Content-length: 1219 In article , Mark Hindley wrote: >I am in the middle of writing a windows namespace extension implemented as >an in process server dll. I have got the basic structure complete and it >builds fine with gcc, but I can not get it to debug with gdb. > >I am trying: > >exec-file /windows/explorer.exe > >source-file MyDll.dll > >set args /root, {My CLSID}, > > >There appears to be 2 problems. I get an access violation when the dll is >read, eith as the initial symbol file, or when it is loaded by explorer >when the programme is run. The other is that I am unable to set any >breakpoints. If I type > >break DllMain > >the reply is > >Cannot access memory at 0x.... The way that I normally do something like this is: gdb /windows/explorer.exe symbol-file MyDll.dll set args /root l DllMain bp run As you probably, know using 'symbol-file' wipes out any existing symbol file so this may not be exactly what you want. You could use add-sym if you know the load address of your DLL. Hope this helps, Chris Faylor -- cgf@cygnus.com http://www.cygnus.com/ >From ac131313@cygnus.com Sat Nov 27 18:50:00 1999 From: Andrew Cagney To: gdb@sourceware.cygnus.com Subject: -Werror -Wformat -Wimplicit Date: Sat, 27 Nov 1999 18:50:00 -0000 Message-id: <37CB6DBE.2083662F@cygnus.com> X-SW-Source: 1999-q4/msg00334.html Content-length: 1339 Just FYI, The next snap (Jason only just made one) is very likely to be buildable with the configuration option: --enable-build-warnings=-Werror\ ,-Wimplicit\ ,-Wreturn-type\ ,-Wcomment\ ,-Wtrigraphs\ ,-Wformat\ ,-Wparentheses\ ,-Wpointer-arith\ ,-Woverloaded-virtual I've cleaned up numerous targets and, for them, the source code contains *ZERO* warnings of the types listed above. Assuming that your host's header files are in good condition, it shouldn't take much for a few maintainers to wack their native build into similar shape. For the curious. The full list looks like: enable_build_warnings=`echo -Werror\ \ ,$W\ ,-Wimplicit\ ,-Wreturn-type\ ,$Wunused\ ,$Wswitch\ ,-Wcomment\ ,-Wtrigraphs\ ,-Wformat\ ,$Wchar$subscripts\ ,$Wuninitialized\ ,-Wparentheses\ ,$Wtemplate$debugging\ \ ,$Wtraditional\ ,$Wshadow\ ,$Wid$clash$len\ ,-Wpointer-arith\ ,$Wcast$qual\ ,$Wcast$align\ ,$Wwrite$strings\ ,$Wconversion\ ,$Waggregate$return\ ,$Wstrict$prototypes\ ,$Wmissing$prototypes\ ,$Wmissing$declarations\ ,$Wredundant$decls\ ,$Wnested$externs\ ,$Wenum$clash\ ,-Woverloaded-virtual\ ,$Winline\ so while there is a long way to go, the list of those working is very useful (namely -Wformat, -Wimplicit, -Wparen and -Wcomment - especially -Wformat!). enjoy, Andrew >From msnyder@cygnus.com Sat Nov 27 18:50:00 1999 From: Michael Snyder To: gdb@sourceware.cygnus.com Cc: ptr@paragraph.ru Subject: Re: gdb 4.18 on Solaris 7 x86? Date: Sat, 27 Nov 1999 18:50:00 -0000 Message-id: <37CC6A59.5106@cygnus.com> References: <14273.5137.480144.257285@icecle> X-SW-Source: 1999-q4/msg00339.html Content-length: 1844 Petr Ovchenkov wrote: > > Is anybody made 4.18 working under Solaris 7 x86? I don't have a Solaris 7 x86 system, but it works fine for me on Solaris 6 x86. I'm not sure what might have changed in Solaris 7. > I made changes in gdb/procfs.c so no more > "Inappropriate ioctl for device" happens, and correct permittions for > /proc/XXXX/crt. But still can't set any breakpoint (indeed can, > but gdb don't stop on it). Can't comment without seeing your changes. I've never seen that message, and breakpoints are working fine for me on Solaris 6 x86. > > more test.c > #include > > int main( int argc, char **argv ) > { > printf( "%s", "Hello, GNU!\n" ); > return 0; > } > > gcc -ggdb test.c -lthread Just curious -- why are you linking libthread to this program? > GNU gdb 4.18 > Copyright 1998 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-pc-solaris2.7"... > (gdb) break main > Breakpoint 1 at 0x80489b2: file test.c, line 5. > (gdb) run > Starting program: /export/home/ptr/tmp/Test/a.out > Hello, GNU! > /proc/11504/ctl: No such file or directory. > procfs_write_pcwstop failed > (gdb) quit > The program is running. Exit anyway? (y or n) y > > > > When gdb say "/proc/11504/ctl: No such file or directory.", process > already exited. When I try "target solaris-thread", result the same. > > Can any help? > > If somebody interesting by /proc/... workaround for Solaris 7, > patch for available. I'd be willing to look at your patch. Michael Snyder >From jingham@leda.cygnus.com Sat Nov 27 18:50:00 1999 From: James Ingham To: gdb@sourceware.cygnus.com Subject: Re: Next release of GDB Date: Sat, 27 Nov 1999 18:50:00 -0000 Message-id: References: <199909051618.SAA01412@caracol.first.gmd.de> X-SW-Source: 1999-q4/msg00341.html Content-length: 1942 Clemens Klein-Robbenhaar writes: Presumably, the Objective C support would be in the MacOS X Support bits. MacOS X being based on NextStep, which is in turn heavily Objective C based... Jim > Stan Shebs wrote: > > [...] > > Here are some additional things that I would like to see, but that > > ought not to hold up the release if they can't be gotten in: > > > > * first version of libgdb, w/Guile scripting > > * GNU/Linux thread_db library support > > * asynchronous execution for GNU/Linux > > * fork following for GNU/Linux > > * HP WDB 1.1 bits >>>>>>>>>>>> > * Apple MacOS X support bits > > * Current VxWorks (Tornado) support bits > > * Current LynxOS support bits > > * m68k BDM patches > > * Ada language support > > > > There are probably many other important things that I'm forgetting, > > please speak up and remind me about them! > [...] > > .. what about Objective C support? That should not be to hard. > (For gdb-4.16 and gdb-4.17, there was a patch, > afaik by Michael Snyder ; > still present at ftp://alpha.gnu.org/gnu/gnustep/contrib > This patch does not work for gdb-4.18, but only because the code > changed too much for the "patch" program to apply, I think.) > > Have I missed some point here -- has the Objective C patch > been rejected because of pricipal reasons not supporting Objective C > in gdb? As I scanned the archives, I found only > Christopher Seawood > http://sourceware.cygnus.com/ml/gdb-patches/1998/msg00115.html > raising the same issue, but without getting any feedback. > > Or has just nobody been around so far interested in doing the > (little) work? > > > regards, > clemens -- ++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++ Jim Ingham jingham@cygnus.com Cygnus Solutions Inc. >From msnyder@cygnus.com Sat Nov 27 18:50:00 1999 From: Michael Snyder To: gdb@sourceware.cygnus.com Subject: Re: overlays and hardware breakpoints Date: Sat, 27 Nov 1999 18:50:00 -0000 Message-id: <37D5CAFE.7F3B@cygnus.com> References: <5mwvu8ft9t.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q4/msg00343.html Content-length: 386 J.T. Conklin wrote: > But while studying breakpoint.c, I noticed that there does not seem > to be support for using hardware breakpoints and overlays. Although > CPUs with hardware breakpoint registers typically have large address > spaces, it is not inconceivable that overlays may be used. Almost surely an oversight. If you care to add it, I'll review it. Michael >From ac131313@cygnus.com Sat Nov 27 18:50:00 1999 From: Andrew Cagney To: gdb@sourceware.cygnus.com Subject: ERF TARGET_WAITKIND_EOF Date: Sat, 27 Nov 1999 18:50:00 -0000 Message-id: <37F0529C.B0694A78@cygnus.com> X-SW-Source: 1999-q4/msg00337.html Content-length: 1119 Hello, (I've also seen LOST, DEAD, DOA, KABOOM, KAPUT ..suggested :-). At present when communication with a target is lost, the target internally indicates the falure by directly killing the target (mourn_inferior()) and longjmping out of there (error ()). When it comes to async and providing clean library like behavour, having things randomly call error() isn't nice (besides longjmp's are bad N'kay ;-). I'd like to propose the new ``enum target_waitkind'' TARGET_WAITKIND_EOF that target_wait() can return to indicate that the target just went kaput. The semantics would require the target_*() vector to post the the failure reason on gdb_stderr and then return TARGET_WAINTKIND_EOF. Initially the remote async and remote extended-async targets would be the only ones capable of returning this result. This would ensure that other non-async targets would not be affected. Clearly this is going to stur up WFI (or what ever it is today). I'd like comments on this and (perhaphs) someone willing to handle the WFI side. I'd be willing to take care of the remote.c side. Andrew >From msnyder@cygnus.com Sat Nov 27 18:50:00 1999 From: "Michael Snyder" To: gdb@sourceware.cygnus.com Subject: Re: Lets talk to each other... Date: Sat, 27 Nov 1999 18:50:00 -0000 Message-id: <7svnb4$5cb$1@cronkite.cygnus.com> References: <19990927151348.A22339@sco.com> <990928043014.ZM29997@ocotillo.lan> <199909280657.IAA00175@delius.kettenis.nl> <990929033103.ZM17365@ocotillo.lan> <199909291554.RAA18158@landau.wins.uva.nl> X-SW-Source: 1999-q4/msg00345.html Content-length: 307 Mark Kettenis wrote in message <199909291554.RAA18158@landau.wins.uva.nl>... >HJ's patch has >the drawback that it also tries to solve a totally unrelated problem >(curses on Solaris 7), which needs some more investigation and >probably should be And is being. >fixed in autoconf instead. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: gdb@sourceware.cygnus.com Subject: -Wmissing-prototypes ... Date: Mon, 20 Sep 1999 00:46:00 -0000 Message-ID: <37E5E508.D56E054C@cygnus.com> X-SW-Source: 1999-q3/msg00369.html Message-ID: <19990920004600.7Cgmm-DMFdVIHnYr0CugHQSqk6am4bFEJMz0l4_0Fr8@z> FYI, There is now a reasonable chance that GDB can be compiled with the -Wmissing-prototypes option. Thanks to JimI, JimB and Fernando and Elena for various specific cleanups. Andrew My current list is: --enable-build-warnings=-Werror\ ,-Wimplicit\ ,-Wreturn-type\ ,-Wcomment\ ,-Wtrigraphs\ ,-Wformat\ ,-Wparentheses\ ,-Wpointer-arith\ ,-Wmissing-prototypes\ ,-Woverloaded-virtual\ >From ac131313@cygnus.com Mon Sep 20 19:47:00 1999 From: Andrew Cagney To: Ovidiu Predescu Cc: Jim Blandy , Stan Shebs , gdb@sourceware.cygnus.com Subject: Re: libGDB architecture Date: Mon, 20 Sep 1999 19:47:00 -0000 Message-id: <37E6F077.F75C8BE8@cygnus.com> References: <199909162200.PAA21351@hercules.cup.hp.com> X-SW-Source: 1999-q3/msg00370.html Content-length: 3693 Ovidiu Predescu wrote: > > On 16 Sep 1999 14:08:39 -0500, Jim Blandy wrote: > > > How should we handle objects allocated on obstacks? Most of the > > symbolic info (types; variables) is allocated this way. I don't think > > it's practical to keep the entire obstack around until all its > > objects' reference counts have dropped to zero. > > I think we should expect clients to behave nicely and not keep references to > such objects around for an indefinite time. Once they get a message that such > an object became invalid, the client should release its reference. Another > approach for the client would be to copy such information in its own internal > data structures, if they are needed for a longer time, but this shouldn't be > the case. To re-iterate my position, as a first pass, I strongly prefer to keep a certain distance between GDB's internals and the client. When it comes to performance, I can't see the access mechanisms provided for primitives such as breakpoints and frames even appearing on the radar. In fact, to the best of my knowledge the current biggest hot spot (everyone keeps pointing a finger at) is the overhead/hazards of serializing GDB's communication (via a pty say). I think a better (safer, more likely to succeed) approach would be to, in parallel with the introduction of a robust interface, start investigating what have been identified as other (likely) hot spots. Interestingly, many of the below are actually independent of the libGDB interface: o variable update when stepping I believe that the GDBtk team (who do access GDB's internals using a more direct mechanism) have already identified this as a performance hot spot. o A per thread cache. Well actually the lack of it :-) Here is another example of why it is better to have the client keep a safe distance from GDB. The last thing we want is for clients to be locked into the existing mechanisms. o memory transfer / large target data structures In this case I think more fundamental internal GDB changes will be needed before you can start thinking about providing direct access to GDB's internal memory structures. Perhaps HP are interested in taking on the task of re-working GDB's local memory cache so that a more direct interface is possible. I kind of suspect that papers on distributed shared memory would be highly relevant. While that work is in progress a slow robust mechanism would continue to be used. o (as always) symbol table / name lookup A hot topic in anyone's language :-) > Releasing the obstacks happens usually as a result of an action triggered by > the client, so it should be prepared to release these objects. We can document > which are those functions in the API that deallocate entire obstacks; these > shouldn't be that many, the only important places I can think of are associated > with freeing of an object file and reloading of symbols. (Stack frames are implemented using obstacks.) I don't think it is reasonable to assume that the client is in control :-). As GDB becomes more and more asynchronous it is just as likely that the target will trigger events as it is the client. Consider GDB debugging a multi-threaded target. The long term plan is for GDB to allow some threads to run free while others are halted - in such a situation any assumption that the client is in control has to be thrown out the window :-). > Either way we need the client's cooperation, which is what you require anyway > from somebody that lives with you in the same data space ;-). Your too trusting :-) Andrew PS: See Tcl_IncrRefCount and Tcl_DecrRefCount >From ac131313@cygnus.com Mon Sep 20 22:45:00 1999 From: Andrew Cagney To: Stan Shebs Cc: cagney@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: QUIT as a function? Date: Mon, 20 Sep 1999 22:45:00 -0000 Message-id: <37E71AEB.B9C35E7D@cygnus.com> References: <199909171842.LAA10740@andros.cygnus.com> X-SW-Source: 1999-q3/msg00371.html Content-length: 736 Stan Shebs wrote: > > From: Andrew Cagney > Date: Fri, 17 Sep 1999 15:14:42 +1000 > > Is there any reason for not converting QUIT into a function? > > Yes, QUIT appears in the inner loops of the symbol readers, which > are known to be compute-bound and some of the most time-critical > code in all GDB. So I'd want to see some comparative performance > numbers, especially on hosts with lame calling conventions, before > we go messing with QUIT. True. I guess a pre-cursor would be to ``fix'' the symbol table stuff so that it wasn't so dependent on linear search algorithms :-(. The performance gains made there should more than out way any performance loss with an extra function call. Andrew >From jingham@leda.cygnus.com Tue Sep 21 11:31:00 1999 From: James Ingham To: gdb@sourceware.cygnus.com Subject: Re: libGDB architecture Date: Tue, 21 Sep 1999 11:31:00 -0000 Message-id: References: <199909162200.PAA21351@hercules.cup.hp.com> <37E6F077.F75C8BE8@cygnus.com> X-SW-Source: 1999-q3/msg00372.html Content-length: 2073 Andrew Cagney writes: > > I think a better (safer, more likely to succeed) approach would be to, > in parallel with the introduction of a robust interface, start > investigating what have been identified as other (likely) hot spots. > Interestingly, many of the below are actually independent of the libGDB > interface: > I agree with Andrew here. We can get a lot of benefit just breaking down some of the atomic operations in the GDB interface into useable bits. We have already done this with the variable interface (see gdbtk-variable.c) Another example where you need to do this is in the backtrace command. For most GUI purposes, you really don't want an undifferentiated list of 100 stack elements with all their arguments, names, types... Parsing and displaying this was very slow. You really want one command that just gives you the list of functions on the stack. Then a way to get the args (preferrably already list-ified) for each level. That way you can do intelligent things like only fetch what fits in the current window, and get the others on scrolling or whatever... This is just one other example. There are other places where providing a more discrete interface into gdb would be a big benefit, and probably reduce most of the need to get your hands on the actual data in gdb. I am still worried about parsing very large arrays, etc, however. For this to be fast, you probably will have to somehow get the data directly... > Your too trusting :-) > > Andrew > > PS: See Tcl_IncrRefCount and Tcl_DecrRefCount There are actually two places where Tcl does preservation of data. One is in the Object system, which uses the calls Andrew sites above, and one is for clients that want to hold data over a call that may potentially free it - see Tcl_Preserve and Tcl_EventuallyFree. Jim -- ++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++ Jim Ingham jingham@cygnus.com Cygnus Solutions Inc. >From masahiro@lsi.nec.co.jp Wed Sep 22 02:35:00 1999 From: Masahiro Fukuda To: gdb@sourceware.cygnus.com Cc: masahiro@lsi.nec.co.jp Subject: one proposal ... `Z'T`,'ADDR`,'LENGTH`,'IGNORE_COUNT ?? Date: Wed, 22 Sep 1999 02:35:00 -0000 Message-id: <199909220933.SAA06550@mctcs13.ucom.lsi.nec.co.jp> X-SW-Source: 1999-q3/msg00373.html Content-length: 7368 Hi, I recently realize that gdb-19990830 extends some keyword into gdb serial protocol, and I also read some mailing list archives. My name is Masahiro Fukuda. Independently, I added some keyword (actually [B/b] just like J.T.C did) into gdb serial protocol in order to transmit "breakpoint" to gdbserver instead of writing TRAP instruction. Some arguements including , , follow breakpiont keyword in my code. Those command packets are generated in v850_insert_hw_breakpint()/v850_insert_watchpoint() in v850-tdep.c. Andrew suggested me that I would join gdb mailing list when I wrote an e-mail to him how I should do for this kind of proposal. Expected typical scenario is shown below when ignore count is transmitted to target. Suppose, there are three breakponits/watchpoints and each has following ignore count. number type ignore count ------------------------------------------ #1 hardware breakpoint 7 #2 read watchpoint 5 #3 write watchpoint 3 Please find the gdb/target communication below with illustration. (a) Breakpoints/watchpoints are inserted before continue. (b) Gdb continues target. Target decrements each ignore count every time when target hits respective breakpoint/watchpoint without making any communication with gdb as far as respective ignore count does not equal to zero. At last, target tells gdb after it hits breakpoint/watchpoint whose ignore count equal to zero. (c) breakpoints/watchpoints are removed after target stopps and each current ignore count is retrieved from target. ---------------------- illustration ---------------------- gdb side -------------------- target side (a)insert breakpoints -----------------------> (#1, 7) before continue -----------------------> (#2, 5) with ignore count -----------------------> (#3, 3) (b)continue -----------------------------------> wait for target | #1 hit (#1, 7->6) to stop | #1 hit (#1, 6->5) | #1 hit (#1, 5->4) | #2 hit (#2, 5->4) time | #3 hit (#3, 3->2) | #1 hit (#1, 4->3) | #1 hit (#1, 3->2) | #1 hit (#1, 2->1) | #2 hit (#2, 4->3) | #3 hit (#3, 2->1) | #1 hit (#1, 1->0) V #1 hit (#1, 0->!) target stop <------------------------------- (c)remove breakponits -----------------------> (#1 ) remained ignore count returns (0) <--------- remove breakponits -----------------------> (#2 ) remained ignore count returns (3) <--------- remove breakponits -----------------------> (#3 ) remained ignore count returns (1) <--------- ---------------------- illustration ---------------------- Next, please find the proposed Z/z packet. ---------------------- proposed Z/z packet ---------------------- remove `z'T`,'ADDR`,'LENGTH` `z' should retrieve break remained IGNORE_COUNT or from target. watcchpoint reply `OK'IGNORE_COUNT for success The others are the same as current spec. insert `Z'T`,'ADDR`,'LENGTH`,'IGNORE_COUNT just add IGNORE_COUNT break The othera are the same or as current spec. watcchpoint ---------------------- proposed Z/Z packet ---------------------- ---------------------- current Z/Z packet ---------------------- remove break or `z'T`,'ADDR`,'LENGTH See `Z'. watchpoint *(draft)* *(optional)* insert break or `Z'T`,'ADDR`,'LENGTH T is type: `0' - software watchpoint *(draft)* breakpoint, `1' - hardware *(optional)* breakpoint, `2' - write watchpoint, `3' - read watchpoint, `4' - access watchpoint; ADDR is address; LENGTH is in bytes. For a software breakpoint, LENGTH specifies the size of the instruction to be patched. For hardware breakpoints and watchpoints LENGTH specifies the memory region to be monitored. reply `E'NN for an error reply `OK' for success `' If not supported. ---------------------- current Z/Z packet ---------------------- Some fragment of my code is shown below. I will follow snapshot specification(I will modify my code to adjust snapshot specification) such like.... B -> Z w -> 2 r -> 3 a -> 4 ---------------------- cut cut cut ---------------------- int v850_insert_watchpoint(addr,len,type) int addr, len, type; { char buf[PBUFSIZ], *p; struct breakpoint *b, *tmp; /* breakpoint.c */ int ignore_count; /* see breakpoint.h */ value_ptr v; /* see breakpoint.h */ int watch_addr; /* construct "Bw"","","" if type == 0 */ /* construct "Br"","","" if type == 1 */ /* construct "Ba"","","" if type == 2 */ /* sprintf (buf, "Bx%lx,%x,%x", (unsigned long) memaddr, len, ignore); */ p = buf; *p++ = 'B'; if (type == 0) *p++ = 'w'; else if (type == 1) *p++ = 'r'; else if (type == 2) *p++ = 'a'; else error ("(_o_) sorry...watchpoint has wrong value for 'type' "); p += hexnumstr (p, (ULONGEST) addr); *p++ = ','; p += hexnumstr (p, (ULONGEST) len); *p++ = ','; ignore_count = 0; ALL_BREAKPOINTS_SAFE(b, tmp) { if (b->exp != NULL) { v = evaluate_expression (b->exp); watch_addr = VALUE_ADDRESS(v) + VALUE_OFFSET(v); if ( watch_addr == addr) { ignore_count = b->ignore_count; b->ignore_count = 0; break; } } } p += hexnumstr (p, (ULONGEST) ignore_count); *p++ = ':'; *p = '\0'; putpkt (buf); getpkt (buf, 0); return 0; /* 0 when success, -1 when failure */ } ---------------------- cut cut cut ---------------------- Best regards, Fukuda, M >From ac131313@cygnus.com Wed Sep 22 23:16:00 1999 From: Andrew Cagney To: gdb@sourceware.cygnus.com Subject: Context attached to a command? Date: Wed, 22 Sep 1999 23:16:00 -0000 Message-id: <37E9C499.19EF2B1E@cygnus.com> X-SW-Source: 1999-q3/msg00374.html Content-length: 458 Hello, Do any of the existing command.h functions allow you to associate some sort of context with the command? For instance, add_cmd() takes a function callback(char*arg, int from_tty); the assumption being that the function can pick up any relevant data from globals. Is there an equivalent: calloback(void *context, char *arg, int from_tty); where ``context'' was passed to the original add_command? If not, I'll add it. Andrew >From jtc@redback.com Thu Sep 23 13:53:00 1999 From: jtc@redback.com (J.T. Conklin) To: Masahiro Fukuda Cc: gdb@sourceware.cygnus.com Subject: Re: one proposal ... `Z'T`,'ADDR`,'LENGTH`,'IGNORE_COUNT ?? Date: Thu, 23 Sep 1999 13:53:00 -0000 Message-id: <5mg1051hdv.fsf@jtc.redbacknetworks.com> References: <199909220933.SAA06550@mctcs13.ucom.lsi.nec.co.jp> X-SW-Source: 1999-q3/msg00375.html Content-length: 2635 >>>>> "Masahiro" == Masahiro Fukuda writes: Masahiro> My name is Masahiro Fukuda. Independently, I added some Masahiro> keyword (actually [B/b] just like J.T.C did) into gdb serial Masahiro> protocol in order to transmit "breakpoint" to gdbserver Masahiro> instead of writing TRAP instruction. Masahiro> Some arguements including , , Masahiro> follow breakpiont keyword in my code. Those command packets Masahiro> are generated in v850_insert_hw_breakpint()/ Masahiro> v850_insert_watchpoint() in v850-tdep.c. I didn't think about breakpoints with ignore counts when developing the breakpoint extension proposal. I did want to allow the stub to manage thread specific breakpoints, which are similar. I also spent some time thinking about how to support conditional breakpoints. My current thoughts are to use an easily parsed stack based expression syntax, but I'm not actively pursuing this feature. The problem with breakpoints with ignore counts is the synchronization of the count between GDB and the stub. As I understand your proposal, you address this by having the 'remove breakpoint' command return how many counts are left for each breakpoint. Unfortunately, I believe that this conflicts with another project that I'm working on. I've been changing GDB so that breakpoints are not inserted or removed from the target unless it is absolutely necessary to do so. At present, whenever you step through code, the active breakpoints are inserted, the code is executed, then the breakpoints are removed. If the user is using a lot of breakpoints, this greatly increases the time it takes to step through code. If GDB must sync ignore counts by removing breakpoints, that precludes this optimization. Perhaps an additional command that lists managed breakpoints and their ignore count (if any) is needed. Another possible problem is that our current model is that duplicate breakpoints are ignored when they are inserted. A breakpoint is uniquely defined by , , , and possibly if threads specific breakpoints are supported. But how can the stub tell the differences between two breakpoints when the only difference is the ignore count? This may require the stub to return a handle when a breakpoint is inserted so that GDB can uniquely identify it. I'm not saying this is a bad idea. Actually, this is the kind of thing a stub can keep track of fairly trivally yet greatly reduce the amount of debug protocol overhead. But I think it needs a bit more refinement. Thoughts? --jtc -- J.T. Conklin RedBack Networks >From shenoy@wipinfo.soft.net Thu Sep 23 22:30:00 1999 From: "Narayan Shenoy R" To: Subject: Support for native Sun Workshop debugging format ... Date: Thu, 23 Sep 1999 22:30:00 -0000 Message-id: <199909240530.LAA02001@gem.wipinfo.soft.net> X-SW-Source: 1999-q3/msg00376.html Content-length: 482 We are using native WorkShop debugging format (non -xs) for building our parallel applications. gdb is known to have problems recognizing this format. Reverting to -xs format is unacceptable since each of the libraries build that way occupies close to 150 MB of space. Are there any plans on supporting native WorkShop debugging format? If so, any pointers to anyone who is working on that at present. Please help. Thanks, Shenoy Narayan Shenoy R ph: 5530034/35/36 extn. 1055