This is the mail archive of the insight@sources.redhat.com mailing list for the Insight project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Bugs/Features


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]