"p" uses the expression parser and might cause code to be jitted and run in the
program being debugged. If the expression is simple enough, the expression
parser will emulate the IR. With "frame variable", it doesn't use the
expression parser. "frame variable" can display children: "pt.x" or "pt
Hi Enrico/Greg,
Can you help me to understand what is the difference between "p" and "fr v"
command to print local variables? My data formatter works fine in all cases
of "fr v", and will fail for "p" command in some case(implementation at the
end). In the debug log output below, you can see, when
After removing the "-x" and apply the formatter to "std::string" instead of
fbstring_core, it works fine now. Thanks!
On Wed, Apr 20, 2016 at 3:24 PM, Enrico Granata wrote:
>
> On Apr 20, 2016, at 3:08 PM, Jeffrey Tan wrote:
>
> Hi Enrico,
>
> Instead of trying function-evaluation c_str(), I de
> On Apr 20, 2016, at 3:08 PM, Jeffrey Tan wrote:
>
> Hi Enrico,
>
> Instead of trying function-evaluation c_str(), I decided to decode the
> information from fbstring_core fields. I got it working but have two
> questions for it.
>
> type summary add -F data_formatter.folly_string_formatter
Hi Enrico,
Instead of trying function-evaluation c_str(), I decided to decode the
information from fbstring_core fields. I got it working but have two
questions for it.
type summary add -F data_formatter.folly_string_formatter -x
"std::fbstring_core"
Here is the output:
fr v -T small
(std::stri
In theory what you're doing looks like it should be supported. I am not sure
why your example is failing the way it is.
Is your variable a global maybe?
Also, using the variable name is the wrong thing to do. If you have a class
with a std::string member, the name is going to return the wrong t
> On Apr 13, 2016, at 10:11 AM, Jeffrey Tan wrote:
>
> One quick question: do we support getting type summary string from inferior
> method call?
No - for that you are going to need to write a Python formatter.
Running code in formatters is a risky endeavor for a bunch of reasons, so it is
b
I did a quick testing to call SBFrame.EvaluateExpression('string.c_str()')
for the summary. The result shows valobj.GetFrame() returns None so does
this mean this is not supported?
def DoTest(valobj,internal_dict):
print "valobj: %s" % valobj
print "valobj.GetFrame(): %s" % valobj.GetFrame
One quick question: do we support getting type summary string from inferior
method call? After reading our own fbstring_core code, I found I need to
mirror a lot of what fbstring_core.c_str() method is doing in python. I
wonder if we can just call ${var.c_str()} as the type summary? I suspect
one o
> On Apr 6, 2016, at 7:31 PM, Jeffrey Tan wrote:
>
> Thanks Enrico. This is very detailed! I will take a look.
> Btw: originally, I was hoping that data formatter can be added without
> changing the source code. Like giving a xml/json format file telling lldb the
> memory layout/structure of
> On Apr 7, 2016, at 9:51 AM, Jim Ingham wrote:
>
> I don't think Enrico was suggesting that we maintain a bunch of third party
> data formatters in the lldb source base.
That depends - if this std::string implementation is part of a publicly
available STL implementation, it might make sens
I don't think Enrico was suggesting that we maintain a bunch of third party
data formatters in the lldb source base. He was giving C++ examples (using the
lldb_private API's) because the STL formatters are in C++, so that's what he
had on hand to demonstrate the kinds of algorithms you would us
LLDB supports adding data formatters without modifying the source code and
I would strongly prefer to go that way as we don't want each user of LLDB
to start adding data formatters to their own custom types. We have a pretty
detailed (but possible a bit outdated) description about how they work and
Thanks Enrico. This is very detailed! I will take a look.
Btw: originally, I was hoping that data formatter can be added without
changing the source code. Like giving a xml/json format file telling lldb
the memory layout/structure of the data structure, lldb can parse the
xml/json and deduce the fo
> On Apr 5, 2016, at 2:42 PM, Jeffrey Tan wrote:
>
> Hi Enrico,
>
> Any suggestion/example how to add a data formatter for our own STL string?
> From the output below I can see we are using our own "fbstring_core" which I
> assume I need to write a type summary for this type:
>
> frame varia
Hi Enrico,
Any suggestion/example how to add a data formatter for our own STL string?
>From the output below I can see we are using our own "*fbstring_core*"
which I assume I need to write a type summary for this type:
frame variable corpus -T
(const string &const) corpus = error: summary string
Thanks, I will try this escape mechanism for the returned C string.
On Mon, Mar 28, 2016 at 1:04 PM, Greg Clayton wrote:
>
> > On Mar 28, 2016, at 11:38 AM, Jeffrey Tan
> wrote:
> >
> > Thanks Greg for the detailed explanation, very helpful.
> > 1. Just to confirm, the weird string displayed is
> On Mar 28, 2016, at 11:38 AM, Jeffrey Tan wrote:
>
> Thanks Greg for the detailed explanation, very helpful.
> 1. Just to confirm, the weird string displayed is because 'data_' points to
> some random memory?
Yes.
> So what gdb displays is also some random memory content not something that
Thanks Greg for the detailed explanation, very helpful.
1. Just to confirm, the weird string displayed is because 'data_' points to
some random memory? So what gdb displays is also some random memory content
not something that more meaningful than us? I thought we(lldb) did not
display std::string
This is kind of orthogonal to your problem, but the reason why you are not
seeing the kind of simplified printing Greg is suggesting, is because your
std::string doesn’t look like any of the kinds we recognize
Specifically, LLDB data formatters work by matching against type names, and
once they
So you need to be prepared to escape any text that can have special characters.
A "std::string" or any container can contain special characters. If you are
encoding stuff into JSON, you will either need to escape any special
characters, or hex encode the string into ASCII hex bytes.
In debugge
On Sat, Mar 26, 2016 at 11:58 PM, Jeffrey Tan wrote:
> Btw: after patching with Siva's fix http://reviews.llvm.org/D18008, the
> first field 'small_' is fixed, however the second field 'ml_' still emits
> garbage:
>
> (lldb) fr v corpus
> (const string &const) corpus = error: summary string parsin
Thanks Siva. All the *DW_TAG_member *related errors seems to go away after
patching with your fix. The current problem is handling the decoding.
Here is the correct decoding from gdb whic might be useful:
(gdb) p corpus
$3 = (const std::string &) @0x7fd133cfb888: {
static npos = 1844674407370955
Btw: after patching with Siva's fix http://reviews.llvm.org/D18008, the
first field 'small_' is fixed, however the second field 'ml_' still emits
garbage:
(lldb) fr v corpus
(const string &const) corpus = error: summary string parsing error: {
store_ = {
= {
small_ = "www"
ml_ =
24 matches
Mail list logo
