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]
Other format: [Raw text]

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.




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