This is the mail archive of the
mailing list for the Archer project.
Re: [python] StdStringPrinter misleading?
- From: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, archer at sourceware dot org
- Date: Sun, 29 Mar 2009 14:26:32 -0300
- Subject: Re: [python] StdStringPrinter misleading?
- References: <20090328002208.083A33A6BE4@localhost> <firstname.lastname@example.org>
El vie, 27-03-2009 a las 19:35 -0600, Tom Tromey escribiÃ:
> >>>>> "Paul" == Paul Pluzhnikov <email@example.com> writes:
> Paul> std::string could contain embedded NUL characters, and current
> Paul> StdStringPrinter hides this (not that the raw printing is any better):
> The appended almost does it.
I'd prefer if Value.string did the job, like in the current version of
the StdStringPrinter. But I didn't dig into this to find out if it's
Your patch looks like a big workaround, perhaps we can save people from
having to do stuff like this when reading strings from the inferior?
Also, I don't htink it would work with gdb-side values.
> However, it doesn't work because
> pretty_print_one_value loses the length information. I think this
> should not be too hard to deal with... either Phil or I will implement
> this soon.
It seems that python_string_to_host_string should return the string
length, not just the char *. I think that's what you refer to, right?
Ditto for python_string_to_target_string, of course.
This may trigger a chain of changes to make all callers properly use the
string length instead of assuming that char * strings are always
null-terminated. This is the direction all of GDB should go eventually,
by the way. Except code dealing specifically with the C language, of
I believe this comment in pretty_print_one_value is outdated:
/* If we just call convert_value_from_python for this
type, we won't know who owns the result. For this
one case we need to copy the resulting value. */
Jim Blandy fixed convert_value_from_python to always return a
Because of this, pretty_print_one_value can now probably just call
convert_value_from_python in all cases and be done with it. Perhaps
doing this will side-step the issue with python_string_to_host_string,
and allow pretty_print_one_value to always return a struct value instead
of returning a char * sometimes? Would this change fix the problem found
As a side note, I think that convert_value_from_python has a bug in that
it uses python_string_to_target_string. IIUC Python values should be
assumed to be in the host encoding and representation. Perhaps there are
other places with this same bug, I'll have to check that.
> If we go with this patch, we'll need to push the membuf stuff upstream.
I intend to push the membuf stuff upstream for 7.0. But it depends on
implementing the Inferior API first, since read_memory and friends are a
> Perhaps a better plan would be to add a length argument to Value.string.
> Thiago, what do you think?
I think that Value.string should "just know" what the string length is,
adding a length argument sounds like a workaround to me, I'd rather
avoid having to do that.
> + ptr = self.val['_M_dataplus']['_M_p']
> + realtype = self.val.type().unqualified().strip_typedefs()
> + reptype = gdb.Type(str(realtype) + '::_Rep').pointer()
> + header = ptr.cast(reptype) - 1
> + len = header.dereference()['_M_length']
> + charwidth = ptr.type().target().sizeof()
Wow, I think this is a good example of how powerful the value and type
classes turned out to be. I think we're heading in the right direction
Congratulations on the type class.
> + data = gdb.read_memory (long (ptr), long (len) * charwidth)
> + return unicode (data, encoding)
What is your impression of gdb.read_memory, after using it? I think it's
effective and "Pythonic", but I'd like to see if others have an opinion.
I think up to now, I was the only one who actually used it.
Thiago Jung Bauermann
IBM Linux Technology Center