public inbox for insight@sourceware.org
 help / color / mirror / Atom feed
From: Keith Seitz <keiths@cygnus.com>
To: Willem Hajenius <willem.hajenius@ping.be>
Cc: <insight@sourceware.cygnus.com>
Subject: Re: Bugs/Features
Date: Thu, 13 Sep 2001 13:08:00 -0000	[thread overview]
Message-ID: <Pine.GSO.4.33.0109131237200.9617-100000@makita.cygnus.com> (raw)
In-Reply-To: <000201c13c8a$82607f00$32285fc3@hajeniuscomp>

On Thu, 13 Sep 2001, Willem Hajenius wrote:

> * Please provide a window similar to the "Source is more recent than
> executable"-dialog, with a "Don't show this in the future"-checkbox,
> and an Preference setting to enable all disabled messages. (This is
> often forgotten; as a consequence users become fearful to dismiss a dialog
> 'forever'.)
>
> * The checkbox mentioned above doesn't work: the dialog keeps popping up
> in future sessions.

Unfortunately, as you've discovered, the "dismissable" warnings are
renewed every time Insight is run. I think that I can fix this easily
enough, though, but it hints at more inadequacies in the preferences code.
(For example, almost all warning generated by core gdb are not
dismissable.) I have given this some thought, and I think that I can
weasel my way around gdb to get something working (as ugly as it may be).

> * Also make the "i386 Architecture file may be incompatible with i386:intel
> target"-message box dismissable. After hundreds of debugging sessions it
> becomes very annoying.

I have no idea what this is: it is certainly a message from the bowels of
the debugger which alludes to a more serious problem. You might inquire on
the gdb list (gdb@sources.redhat.com) how to get rid of this warning.

> * Add a Preference option to completely expand or contract the compound
> variables in the Local Variables-window. This would prove very
> time-saving, particularly with complex data structures.

We could provide something like this, but we cannot expand *all* levels,
obviously. We could have a preference to set some limit on how many levels
are expanded, though. I would need to give some very serious thought to
the utility of this feature, though. I can imagine defining some sort of
template to be used whenever a specific type shows up in the window,
though. For example, I could see that it would be very convenient to have
a way to tell the variable window that any "struct foo" be expanded
automatically in the window.

I'll jot this down as a feature to investigate when it comes time to
rewrite the locals and watch windows. (This is one of my highest
priorities with Insight, btw.)

> * (Not quite sure about the exact cause of this one) It appears that when
> an array is (re)alloc'ed, it's representation in the Local Variables-window
> is not updated. Consider the following code snippet:
>
> struct rec
> {
>   char c[5];
> };
>
> typedef struct rec foo;
>
> int main()
> {
>   foo* f;
>   f = (foo*) malloc (10);
>   f->c[9] = 'A';
>   free (f);
>   return 0;
> }
>
> This works perfectly well, yet the Local Variables-window doesn't indicate
> that 'c' is now 10 characters large.

(I must say -- this is an evil coding practice! Why hide the true type of
the variable? If you want to make it opaque, just make it opaque and
cast it when needed. Maybe this is just a bad example??)

I think I see what you mean, but what you are asking is not possible with
ANY debugger that I've ever used. What you've written is very sneaky code,
and the compiler does NOT generate data telling the debugger that you've
done this.

All the debugger knows about is a structure with an array "c" of five
bytes. It _cannot_ ever change this definition on the fly. C/C++
are languages where, for example, "struct rec" will ALWAYS contain a
single five-element character array within main: you cannot willy-nilly
change its type, although you can (and have) "worked around" this in the
example above.

That being said, there is still hope. One of the features being planned
for the new variable windows is a "view as" operator, which will allow the
user to change the view type of a variable on the fly.

Think of the code like this:

struct rec
  {
     char c[5];
  };
typedef struct rec foo;

struct _rec
  {
    char c[9];
  };

int main()
{
  foo* f;
  struct _rec *r;

  f = (foo*) malloc (sizeof (struct _rec));
  r = (struct _rec *) f;
  r->c[9] = 'A';
  free (f);
  return 0;
}

Thus, as long as define a real type in your program, you will be able to
view "f" as this type. You can do this in the currect watch window by
entering the cast in the window at the bottom, i.e., enter "(struct _rec *)f".

I thank you for your suggestions and kind words!
Keith


  reply	other threads:[~2001-09-13 13:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-13 12:27 Bugs/Features Willem Hajenius
2001-09-13 13:08 ` Keith Seitz [this message]
2001-09-13 16:53   ` Bugs/Features Tom Tromey

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=Pine.GSO.4.33.0109131237200.9617-100000@makita.cygnus.com \
    --to=keiths@cygnus.com \
    --cc=insight@sourceware.cygnus.com \
    --cc=willem.hajenius@ping.be \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).