This is the mail archive of the
insight@sources.redhat.com
mailing list for the Insight project.
RE: Problem with unsigned char* data
- From: Emilio Ugo GIUFFRIDA <emilio dot giuffrida at st dot com>
- To: "'Keith Seitz'" <keiths at redhat dot com>
- Cc: <insight at sources dot redhat dot com>
- Date: Mon, 26 Jul 2004 14:28:57 +0200
- Subject: RE: Problem with unsigned char* data
I've resolved the problem!
I found the a way to disabling the string pointed by an address :-))
In the file c-valprint.c, in the function c_val_print , there is this
function call :
i = val_print_string (addr, -1, TYPE_LENGTH
(elttype), stream);
that if returns 0 everything has gone well.
The piece of code is:
if (TYPE_LENGTH (elttype) == 1
&& TYPE_CODE (elttype) == TYPE_CODE_INT
&& (format == 0 || format == 's')
&& addr != 0)
i = val_print_string (addr, -1, TYPE_LENGTH (elttype), stream);
else ....
To disable the behaviour simply replace the function call with :
i = 0 ;
Of course it is a workaround, but I think it could be useful if you want to
be able to ON/OFF the printing of the string pointed by an address by
inserting a radio button in the GUI.
Bye,
Emilio
-----Original Message-----
From: Keith Seitz [mailto:keiths@redhat.com]
Sent: Friday, May 21, 2004 4:50 PM
To: Emilio Ugo GIUFFRIDA
Cc: insight@sources.redhat.com
Subject: Re: Problem with unsigned char* data
On Fri, 2004-05-21 at 03:30, Emilio Ugo GIUFFRIDA wrote:
> It seems that gdb tries to read at 0xffffffff and, for pointers to
> unsigned char, displays by default the string pointed.
>
> Do you know if there is a gdb option disabling this behaviour?
I'm sure there is a way, but for the life of me, I cannot recall/find what
it is. Hopefully another reader out there remembers.
> Where is the point, in the code, where the gui tells the gdb to read
> the local variables?
The variable stuff is all called from a gdb module called "varobj" (short
for variable objects). The actual updating of the variables happens in
VarTree::update_var:
if {[catch {$var value} value]} {
set color $colors(error)
}
The first line asks the variable object to update itself. Eventually, this
will call varobj_update in src/gdb/varobj.c. You could set a break on this
function in gdb and step through it.
Hint: It sounds like you have a reproducible test case. Here's what I would
do. Get to the place in your program where you are ready to print "pt1".
Enter this variable into the watch window. This way, when varobj_update is
called, you don't have to filter through the twenty calls from the update of
all the local variables in the locals window.
That aside, two questions:
Do you have a stack backtrace for the crash?
What version of insight are you using? variables.tcl has been gone for quite
some time...
Keith
PS. Stupid thing to try: grab a newer version of varobj.c and drop it on top
of your older insight/gdb sources.