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