-Wmissing-prototypes ...

[Andrew Cagney <ac131313@cygnus.com>]

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 <ac131313@cygnus.com>
To: Ovidiu Predescu <ovidiu@cup.hp.com>
Cc: Jim Blandy <jimb@cygnus.com>, Stan Shebs <shebs@cygnus.com>, 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 <jimb@cygnus.com> 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 <ac131313@cygnus.com>
To: Stan Shebs <shebs@cygnus.com>
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 <ac131313@cygnus.com>
>    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 <jingham@leda.cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: libGDB architecture
Date: Tue, 21 Sep 1999 11:31:00 -0000
Message-id: <mfn1ugceho.fsf@leda.cygnus.com>
References: <199909162200.PAA21351@hercules.cup.hp.com> <37E6F077.F75C8BE8@cygnus.com>
X-SW-Source: 1999-q3/msg00372.html
Content-length: 2073

Andrew Cagney <ac131313@cygnus.com> 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 <masahiro@lsi.nec.co.jp>
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 <addr>, <length>, <ignore_count> 
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"<memaddr>","<len>","<ignore_count>" if type == 0 */
  /* construct "Br"<memaddr>","<len>","<ignore_count>" if type == 1 */
  /* construct "Ba"<memaddr>","<len>","<ignore_count>" 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 <ac131313@cygnus.com>
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 <masahiro@lsi.nec.co.jp>
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 <masahiro@lsi.nec.co.jp> 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 <addr>, <length>, <ignore_count>
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 <type>, <addr>, <len>, and possibly <thread-id> 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" <shenoy@wipinfo.soft.net>
To: <gdb@sourceware.cygnus.com>
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