Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@redhat.com>
To: Nick Roberts <nick@nick.uklinux.net>
Cc: gdb-patches@sources.redhat.com, bob_rossi@cox.net
Subject: Re: [rfc] Annotation level THREE
Date: Tue, 18 Mar 2003 15:29:00 -0000	[thread overview]
Message-ID: <3E773B59.90403@redhat.com> (raw)
In-Reply-To: <15990.62618.114706.459904@nick.uklinux.net>

>  > >  > Why do you need display-{begin,end}?  -display-insert has been made 
>  > >  > redundant by the varobj stuff - it lets the GUI efficiently track its 
>  > >  > display values outside of the CLI.  
>  > > 
>  > > Variable objects don't auto-display. You seem to have to type
>  > > -var-evaluate-expression each time the program stops. 
>  > 
>  > Why do you need auto-display?  What are you using it for?
>  > 
>  > Remember, every time the target changes (e.g., from a user modifying a 
>  > variable or register), the display needs to be updated.  This is because 
>  > that variable/register has the potential to modify every single value 
>  > being displayed.  Further, unless your using some sort of changes-only 
>  > mechanism, such as provided by the varobj, the display windows are just 
>  > not going to scale.
> 
> You're right. If the user assigns a value to a variable, using my code, the
> display window for that variable won't update in Emacs until the next
> statement is executed.

Even simple things, like trying to compute ``1 + 2'' (rather than 
``1+2'') won't work without MI.

> What do you mean by `not going to scale'?

There are a numer of factors that determine IDE performance (as defined 
by single-step):

- ide screen update (gui overhead)
- ide <-> gdb overhead
- gdb <-> inferior
- system load/overhead

If the IDE refreshes all display elements (instead of those that have 
changed) then single-step performance will be dominated by the number of 
visual elements that need to be refreshed.  Any ide<->gdb overhead will 
be in the noise.

 > Currently if I display an array
> slice, say just a few elements from a large array, I need to parse them from
> output for the whole array. Could I arrange for GDB to just output the elements
> I want using variable objects?

I don't know.  Perhaphs ask this on gdb@ as a specific question.

> Can I get GDB to tell me what the current list of variable objects is?

The assumption is that the IDE is tracking the mapping between each of 
its local display elements and the corresponding varobj.

 > Can
> I generate names for them automatically?

I'm not sure what you mean.  Looking at the doco

-var-create - * i

automatically assigns the varobj name.

Andrew



>  > >  >  The testsuite is a good source of 
>  > >  > varobj examples (unfortunatly lacking from the doco):
>  > >  > http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC565
>  > > 
>  > > The lack of documentation for (and apparent completeness of) GDB/MI is part of
>  > > the problem.
>  > 
>  > Um, the varobj is documented.  It just lacks a vew concrete examples. 
>  > Those can be found by examining the testsuite.  Both Apple and Eclipse 
>  > are using this part of the MI.
> 
> Its a question of resources. I'm one person doing things in my spare time.
> Apple and Eclipse have full time teams dedicated to the task.
> 
>  > >  > The above list also contains thing like field-{begin,end}, 
>  > >  > array-section-{begin,end} et.al.  Why are they needed.
>  > > 
>  > > I use them to parse the output. They could probably go, if necessary, but
>  > > others that you plan to take out *are* needed.
>  > 
>  > Can you please be more specific?
> 
> Perhaps I could turn that question round. Which annotations are you planning
> to keep?
> 
> Nick
> 



  reply	other threads:[~2003-03-18 15:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-11 23:37 Andrew Cagney
2003-03-12 18:54 ` David Carlton
2003-03-12 19:04   ` Andrew Cagney
2003-03-14  0:08 ` Nick Roberts
2003-03-17  0:23   ` Andrew Cagney
2003-03-17 20:07     ` Nick Roberts
2003-03-17 20:38       ` Andrew Cagney
2003-03-18 10:31         ` Nick Roberts
2003-03-18 15:29           ` Andrew Cagney [this message]
2003-03-18 16:00           ` Andrew Cagney
2003-03-18 20:17             ` Bob Rossi
2003-03-12  6:09 Michael Elizabeth Chastain
2003-03-12 14:50 ` Andrew Cagney
2003-03-12 14:56   ` Daniel Jacobowitz
2003-03-12 17:04   ` David Carlton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E773B59.90403@redhat.com \
    --to=ac131313@redhat.com \
    --cc=bob_rossi@cox.net \
    --cc=gdb-patches@sources.redhat.com \
    --cc=nick@nick.uklinux.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox