Re: [lldb-dev] Review of API and remote packets
Hello, Ok for the thread id we may use this QThreadSuffixSupported extension but gdb packets also *don't have userid support *since gdb does not have the concept of user id for trace instances. Also gdb uses seperate packets for trace configuration and starting the trace. On Tue, Apr 12, 2016 at 12:26 PM, Pavel Labath wrote: > LLDB already has the QThreadSuffixSupported extension, which adds the > ";thread:" suffix to a bunch of packets. We could say that if the > client requests this extension, we will support it on these packets as > well. Otherwise we fall back to the "Hg" thingy. > > I haven't looked at how hard it would be to implement that... > > pl > > On 12 April 2016 at 09:01, Ravitheja Addepally > wrote: > > One of the downsides of using the gdb protocol is that these packets are > > stateful meaning the thread id option is not there and the word btrace > > stands for branch trace which basically suggests execution tracing. > > > > On Mon, Apr 11, 2016 at 4:50 PM, Pavel Labath wrote: > >> > >> I think we should reuse packets from the gdb protocol whereever it > >> makes sense. So, if they fit your needs (and a quick glance seems to > >> confirm that), then I think you should use them. > >> > >> On 11 April 2016 at 15:28, Ravitheja Addepally > > >> wrote: > >> > Hello, > >> >Regarding the packet definitions for tracing, how about reusing > >> > the > >> > existing btrace packets ? > >> > > >> > > >> > > https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20btrace%20read > >> > > >> > On Fri, Apr 1, 2016 at 7:13 PM, Greg Clayton > wrote: > >> >> > >> >> We also need to think about all other types of tracing. It might make > >> >> more > >> >> sense to keep these calls on SBProcess and have the calls simply be: > >> >> > >> >> > >> >> lldb::SBTrace lldb::SBProcess::StartTrace(SBTraceOptions > >> >> &trace_options, > >> >> lldb::SBError &error); > >> >> > >> >> And you would need to specify which threads in the SBTraceOptions > >> >> object > >> >> itself?: > >> >> > >> >> SBTraceOptions trace_options; > >> >> > >> >> And then do some like: > >> >> > >> >> trace_options.SetTraceAllThreads(); > >> >> > >> >> And maybe tracing all threads is the default. Or one can limit this > to > >> >> one > >> >> thread: > >> >> > >> >> trace_options.SetThreadID (tid); > >> >> > >> >> Then you start tracing using the "trace_options" which has the notion > >> >> of > >> >> which threads to trace. > >> >> > >> >> lldb::SBError error; > >> >> lldb::SBTrace trace = process.StartTrace(trace_options, error); > >> >> > >> >> It really depends on how all different forms of trace are enabled for > >> >> different kinds of tracing. It takes kernel support to trace only > >> >> specific > >> >> threads, but someone might be debugging a bare board that only has > the > >> >> option tracing all threads on each core. When making an API we can't > >> >> assume > >> >> we can limit this to any threads and even to any process. > >> >> > >> >> Greg > >> >> > >> >> > On Apr 1, 2016, at 2:00 AM, Pavel Labath > wrote: > >> >> > > >> >> > I second Greg's suggestions, and I have some thoughts of my own: > >> >> > > >> >> > - with the proposed API, it is not possible to get a trace for > newly > >> >> > created threads - the process needs to be stopped first, so you can > >> >> > enable trace collection. There certainly are cases where this could > >> >> > be > >> >> > problematic, e.g. if you get a crash early during thread creation > and > >> >> > you want to figure out how you got there. For this to work, we > might > >> >> > need an API like > >> >> > SBProcess::TraceNewThreads(...) > >> >> > or > >> >> > SBProcess::TraceAllThreads(...) > >> >> > with the assumption that "all" also includes newly created threads > in > >> >> > the future. > >> >> > > >> >> > I'm not saying this needs to be done in the first implementation, > but > >> >> > I think that we should at least design the API in a way that will > not > >> >> > make adding this unnecessarily hard in the future (e.g. the idea of > >> >> > returning an SBTrace object might be problematic, since you don't > >> >> > know > >> >> > if/how many threads will be created). > >> >> > > >> >> > > >> >> > > >> >> > Also, thinking about new APIs, should we have a way to mark an API > as > >> >> > incubating/experimental? Maybe it would be good to mark these new > >> >> > APIs > >> >> > as experimental for a while, so we have an option of changing them > in > >> >> > the future, if it turns out we have made the wrong decision. I was > >> >> > thinking of either a naming convention > >> >> > (SBThread::StartTraceExperimental) or some annotation/comment on > the > >> >> > methods. When we are confident this design is good, we can remove > the > >> >> > promote the api into the "stable" set. > >> >> > > >> >> > pl > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > On 31 March 2016 at 18:59, Greg Clayton via lldb-dev > >> >> > wrote: > >> >> >> > >>
Re: [lldb-dev] Review of API and remote packets
Do we need the server to know about the user ids we handed out to the SB API client? AFAIK, you cannot have multiple traces of the same thread running concurrently, so a thread-id should uniquely identify a trace. The user id can then stay a client thing for abstracting the concrete implementation details. Or am I missing something here? On 13 April 2016 at 10:10, Ravitheja Addepally wrote: > Hello, >Ok for the thread id we may use this QThreadSuffixSupported extension > but gdb packets also don't have userid support since gdb does not have the > concept of user id for trace instances. Also gdb uses seperate packets for > trace configuration and starting the trace. > > On Tue, Apr 12, 2016 at 12:26 PM, Pavel Labath wrote: >> >> LLDB already has the QThreadSuffixSupported extension, which adds the >> ";thread:" suffix to a bunch of packets. We could say that if the >> client requests this extension, we will support it on these packets as >> well. Otherwise we fall back to the "Hg" thingy. >> >> I haven't looked at how hard it would be to implement that... >> >> pl >> >> On 12 April 2016 at 09:01, Ravitheja Addepally >> wrote: >> > One of the downsides of using the gdb protocol is that these packets are >> > stateful meaning the thread id option is not there and the word btrace >> > stands for branch trace which basically suggests execution tracing. >> > >> > On Mon, Apr 11, 2016 at 4:50 PM, Pavel Labath wrote: >> >> >> >> I think we should reuse packets from the gdb protocol whereever it >> >> makes sense. So, if they fit your needs (and a quick glance seems to >> >> confirm that), then I think you should use them. >> >> >> >> On 11 April 2016 at 15:28, Ravitheja Addepally >> >> >> >> wrote: >> >> > Hello, >> >> >Regarding the packet definitions for tracing, how about >> >> > reusing >> >> > the >> >> > existing btrace packets ? >> >> > >> >> > >> >> > >> >> > https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20btrace%20read >> >> > >> >> > On Fri, Apr 1, 2016 at 7:13 PM, Greg Clayton >> >> > wrote: >> >> >> >> >> >> We also need to think about all other types of tracing. It might >> >> >> make >> >> >> more >> >> >> sense to keep these calls on SBProcess and have the calls simply be: >> >> >> >> >> >> >> >> >> lldb::SBTrace lldb::SBProcess::StartTrace(SBTraceOptions >> >> >> &trace_options, >> >> >> lldb::SBError &error); >> >> >> >> >> >> And you would need to specify which threads in the SBTraceOptions >> >> >> object >> >> >> itself?: >> >> >> >> >> >> SBTraceOptions trace_options; >> >> >> >> >> >> And then do some like: >> >> >> >> >> >> trace_options.SetTraceAllThreads(); >> >> >> >> >> >> And maybe tracing all threads is the default. Or one can limit this >> >> >> to >> >> >> one >> >> >> thread: >> >> >> >> >> >> trace_options.SetThreadID (tid); >> >> >> >> >> >> Then you start tracing using the "trace_options" which has the >> >> >> notion >> >> >> of >> >> >> which threads to trace. >> >> >> >> >> >> lldb::SBError error; >> >> >> lldb::SBTrace trace = process.StartTrace(trace_options, error); >> >> >> >> >> >> It really depends on how all different forms of trace are enabled >> >> >> for >> >> >> different kinds of tracing. It takes kernel support to trace only >> >> >> specific >> >> >> threads, but someone might be debugging a bare board that only has >> >> >> the >> >> >> option tracing all threads on each core. When making an API we can't >> >> >> assume >> >> >> we can limit this to any threads and even to any process. >> >> >> >> >> >> Greg >> >> >> >> >> >> > On Apr 1, 2016, at 2:00 AM, Pavel Labath >> >> >> > wrote: >> >> >> > >> >> >> > I second Greg's suggestions, and I have some thoughts of my own: >> >> >> > >> >> >> > - with the proposed API, it is not possible to get a trace for >> >> >> > newly >> >> >> > created threads - the process needs to be stopped first, so you >> >> >> > can >> >> >> > enable trace collection. There certainly are cases where this >> >> >> > could >> >> >> > be >> >> >> > problematic, e.g. if you get a crash early during thread creation >> >> >> > and >> >> >> > you want to figure out how you got there. For this to work, we >> >> >> > might >> >> >> > need an API like >> >> >> > SBProcess::TraceNewThreads(...) >> >> >> > or >> >> >> > SBProcess::TraceAllThreads(...) >> >> >> > with the assumption that "all" also includes newly created threads >> >> >> > in >> >> >> > the future. >> >> >> > >> >> >> > I'm not saying this needs to be done in the first implementation, >> >> >> > but >> >> >> > I think that we should at least design the API in a way that will >> >> >> > not >> >> >> > make adding this unnecessarily hard in the future (e.g. the idea >> >> >> > of >> >> >> > returning an SBTrace object might be problematic, since you don't >> >> >> > know >> >> >> > if/how many threads will be created). >> >> >> > >> >> >> > >> >> >> > >> >> >> > Also, thinking about new APIs, should we have a way to mark an API >>
Re: [lldb-dev] Review of API and remote packets
Well the point of the user ids was to support multiple trace technologies for the same thread, so in that case the thread id is not sufficient for uniquely identifying the trace. Now I guess the server would need to be aware of the user-id if multiple trace technologies are active on the same thread ? On Wed, Apr 13, 2016 at 12:52 PM, Pavel Labath wrote: > Do we need the server to know about the user ids we handed out to the > SB API client? AFAIK, you cannot have multiple traces of the same > thread running concurrently, so a thread-id should uniquely identify a > trace. The user id can then stay a client thing for abstracting the > concrete implementation details. Or am I missing something here? > > > On 13 April 2016 at 10:10, Ravitheja Addepally > wrote: > > Hello, > >Ok for the thread id we may use this QThreadSuffixSupported > extension > > but gdb packets also don't have userid support since gdb does not have > the > > concept of user id for trace instances. Also gdb uses seperate packets > for > > trace configuration and starting the trace. > > > > On Tue, Apr 12, 2016 at 12:26 PM, Pavel Labath > wrote: > >> > >> LLDB already has the QThreadSuffixSupported extension, which adds the > >> ";thread:" suffix to a bunch of packets. We could say that if the > >> client requests this extension, we will support it on these packets as > >> well. Otherwise we fall back to the "Hg" thingy. > >> > >> I haven't looked at how hard it would be to implement that... > >> > >> pl > >> > >> On 12 April 2016 at 09:01, Ravitheja Addepally > > >> wrote: > >> > One of the downsides of using the gdb protocol is that these packets > are > >> > stateful meaning the thread id option is not there and the word btrace > >> > stands for branch trace which basically suggests execution tracing. > >> > > >> > On Mon, Apr 11, 2016 at 4:50 PM, Pavel Labath > wrote: > >> >> > >> >> I think we should reuse packets from the gdb protocol whereever it > >> >> makes sense. So, if they fit your needs (and a quick glance seems to > >> >> confirm that), then I think you should use them. > >> >> > >> >> On 11 April 2016 at 15:28, Ravitheja Addepally > >> >> > >> >> wrote: > >> >> > Hello, > >> >> >Regarding the packet definitions for tracing, how about > >> >> > reusing > >> >> > the > >> >> > existing btrace packets ? > >> >> > > >> >> > > >> >> > > >> >> > > https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20btrace%20read > >> >> > > >> >> > On Fri, Apr 1, 2016 at 7:13 PM, Greg Clayton > >> >> > wrote: > >> >> >> > >> >> >> We also need to think about all other types of tracing. It might > >> >> >> make > >> >> >> more > >> >> >> sense to keep these calls on SBProcess and have the calls simply > be: > >> >> >> > >> >> >> > >> >> >> lldb::SBTrace lldb::SBProcess::StartTrace(SBTraceOptions > >> >> >> &trace_options, > >> >> >> lldb::SBError &error); > >> >> >> > >> >> >> And you would need to specify which threads in the SBTraceOptions > >> >> >> object > >> >> >> itself?: > >> >> >> > >> >> >> SBTraceOptions trace_options; > >> >> >> > >> >> >> And then do some like: > >> >> >> > >> >> >> trace_options.SetTraceAllThreads(); > >> >> >> > >> >> >> And maybe tracing all threads is the default. Or one can limit > this > >> >> >> to > >> >> >> one > >> >> >> thread: > >> >> >> > >> >> >> trace_options.SetThreadID (tid); > >> >> >> > >> >> >> Then you start tracing using the "trace_options" which has the > >> >> >> notion > >> >> >> of > >> >> >> which threads to trace. > >> >> >> > >> >> >> lldb::SBError error; > >> >> >> lldb::SBTrace trace = process.StartTrace(trace_options, error); > >> >> >> > >> >> >> It really depends on how all different forms of trace are enabled > >> >> >> for > >> >> >> different kinds of tracing. It takes kernel support to trace only > >> >> >> specific > >> >> >> threads, but someone might be debugging a bare board that only has > >> >> >> the > >> >> >> option tracing all threads on each core. When making an API we > can't > >> >> >> assume > >> >> >> we can limit this to any threads and even to any process. > >> >> >> > >> >> >> Greg > >> >> >> > >> >> >> > On Apr 1, 2016, at 2:00 AM, Pavel Labath > >> >> >> > wrote: > >> >> >> > > >> >> >> > I second Greg's suggestions, and I have some thoughts of my own: > >> >> >> > > >> >> >> > - with the proposed API, it is not possible to get a trace for > >> >> >> > newly > >> >> >> > created threads - the process needs to be stopped first, so you > >> >> >> > can > >> >> >> > enable trace collection. There certainly are cases where this > >> >> >> > could > >> >> >> > be > >> >> >> > problematic, e.g. if you get a crash early during thread > creation > >> >> >> > and > >> >> >> > you want to figure out how you got there. For this to work, we > >> >> >> > might > >> >> >> > need an API like > >> >> >> > SBProcess::TraceNewThreads(...) > >> >> >> > or > >> >> >> > SBProcess::TraceAllThreads(...) > >> >> >> > with the assumptio
[lldb-dev] [Bug 27336] New: Float128 not handled in ClangASTContext::GetEncoding
https://llvm.org/bugs/show_bug.cgi?id=27336 Bug ID: 27336 Summary: Float128 not handled in ClangASTContext::GetEncoding Product: lldb Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: ema...@freebsd.org CC: llvm-b...@lists.llvm.org Classification: Unclassified ../tools/lldb/source/Symbol/ClangASTContext.cpp:4736:21: warning: enumeration va lue 'Float128' not handled in switch [-Wswitch] switch (llvm::cast(qual_type)->getKind()) ^ 1 warning generated. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description
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 of the concern is side-effect(the inferior method may throw exception
or cause problems) but I would not see why this can't be done. By allowing
this we can keep the data formatter truth one copy(in source code) instead
of potential out-of-sync(let say the std::string author decided to change
it implementation, the python data formatter associated with it needs to be
modified at the same time which is a maintain nightmare).
Jeffrey
On Thu, Apr 7, 2016 at 10:33 AM, Enrico Granata wrote:
>
> 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 the data structure, lldb can parse the
> xml/json and deduce the formatting. This is approach used by data
> visualizer in VS debugger:
> https://msdn.microsoft.com/en-us/library/jj620914.aspx
> This will make adding data formatter more extensible/flexible. Any reason
> we did not take this approach?
>
>
> The way I understand the Natvis system, it allows one to provide a bunch
> of expressions that describe how the debugger would go about retrieving the
> interesting data bits
> This has the bonus of being really easy, since you’re writing code in the
> same language/context of the types you’re formatting
> On the other hand it has a few drawbacks, in terms of performance as well
> as safety (imagine trying to run code on an object when said object is in
> an incoherent state)
> The LLDB approach, on the other hand, is that you should try to not run
> code when providing these data formatters. In order to do that, we vend an
> API that can do things such as retrieve child values, read memory, cast
> values, …, all without code execution
> Once you have this kind of API that is not expressed in your source
> language, you might just as well describe it in a scripting language. Hence
> were born the Python data formatters.
> In order for us to gain even more performance for native system types that
> we know we’re gonna run into all the time, we then switched a bunch of the
> “mission critical” formatters from Python to C++
> The Python extension points are still available, as Jim pointed out, and
> you are more than welcome to use those instead of modifying the debugger
> core
>
> Jeffrey
>
> On Wed, Apr 6, 2016 at 11:49 AM, Enrico Granata
> wrote:
>
>>
>> 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 variable corpus -T
>> (const string &const) corpus = error: summary string parsing error: {
>> (std::*fbstring_core*) store_ = {
>> (std::*fbstring_core*::(anonymous union)) = {
>> (char [24]) small_ = "www"
>> (std::fbstring_core::MediumLarge) ml_ = {
>> (char *) data_ = 0x0077
>> "H\x89U\xa8H\x89M\xa0L\x89E\x98H\x8bE\xa8H\x89��_U��D\x88e�H\x8bE\xa0H\x89��]U��H\x89�H\x8dE�H\x89�H\x89���
>> ��L\x8dm�H\x8bE\x98H\x89��IU��\x88]�L\x8be\xb0L\x89��
>> (std::size_t) size_ = 0
>> (std::size_t) capacity_ = 1441151880758558720
>> }
>> }
>> }
>> }
>>
>>
>> Admittedly, this is going to be a little vague since I haven’t really
>> seen your code and I am only working off of one sample
>>
>> There’s going to be two parts to getting this to work:
>>
>> *Part 1 - Formatting fbstring_core*
>>
>> At a glance, an fbstring_core can be backed by two representations.
>> A “small” representation (a char array), and a “medium/large"
>> representation (a char* + a size)
>> I assume that the way you tell one from the other is
>>
>> if (size == 0) small
>> else medium-large
>>
>> If my assumption is not correct, you’ll need to discover what the correct
>> discriminator logic is - the class has to know, and so do you :-)
>>
>> Armed with that knowledge, look in lldb
>> source/Plugins/Language/CPlusPlus/Formatters/LibCxx.cpp
>> There’s a bunch of code that deals with formatting llvm’s libc++
>> std::string - which follows a very similar logic to your class
>>
>> ExtractLibcxxStringInfo() is the function that handles discovering which
>> layout the string uses - where the data lives - and how much data there is
>>
>> Once you have told yourself how much data there is (the size) and where
>> it lives (array or pointer), LibcxxStringSummaryProvider() has the easy
>> task - it sets up a StringPrinter, tells it how much data to print, where
>> to get it from,
Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description
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()
summaryValue = valobj.GetFrame().EvaluateExpression(valobj.name +
'.c_str()')
print "summaryValue: %s" % summaryValue
return 'Summary from c_str(): %s ' % summaryValue.GetSummary()
type summary add -F DoTest -x "std::fbstring_core"
Output:
valobj.GetFrame(): No value
summaryValue: No value
valobj: (std::string) $6 = {
store_ = Summary from c_str(): None
}
Jeffrey
On Wed, Apr 13, 2016 at 10:11 AM, Jeffrey Tan
wrote:
> 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 of the concern is side-effect(the inferior method may throw
> exception or cause problems) but I would not see why this can't be done. By
> allowing this we can keep the data formatter truth one copy(in source code)
> instead of potential out-of-sync(let say the std::string author decided to
> change it implementation, the python data formatter associated with it
> needs to be modified at the same time which is a maintain nightmare).
>
> Jeffrey
>
> On Thu, Apr 7, 2016 at 10:33 AM, Enrico Granata
> wrote:
>
>>
>> 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 the data structure, lldb can parse the
>> xml/json and deduce the formatting. This is approach used by data
>> visualizer in VS debugger:
>> https://msdn.microsoft.com/en-us/library/jj620914.aspx
>> This will make adding data formatter more extensible/flexible. Any reason
>> we did not take this approach?
>>
>>
>> The way I understand the Natvis system, it allows one to provide a bunch
>> of expressions that describe how the debugger would go about retrieving the
>> interesting data bits
>> This has the bonus of being really easy, since you’re writing code in the
>> same language/context of the types you’re formatting
>> On the other hand it has a few drawbacks, in terms of performance as well
>> as safety (imagine trying to run code on an object when said object is in
>> an incoherent state)
>> The LLDB approach, on the other hand, is that you should try to not run
>> code when providing these data formatters. In order to do that, we vend an
>> API that can do things such as retrieve child values, read memory, cast
>> values, …, all without code execution
>> Once you have this kind of API that is not expressed in your source
>> language, you might just as well describe it in a scripting language. Hence
>> were born the Python data formatters.
>> In order for us to gain even more performance for native system types
>> that we know we’re gonna run into all the time, we then switched a bunch of
>> the “mission critical” formatters from Python to C++
>> The Python extension points are still available, as Jim pointed out, and
>> you are more than welcome to use those instead of modifying the debugger
>> core
>>
>> Jeffrey
>>
>> On Wed, Apr 6, 2016 at 11:49 AM, Enrico Granata
>> wrote:
>>
>>>
>>> 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 variable corpus -T
>>> (const string &const) corpus = error: summary string parsing error: {
>>> (std::*fbstring_core*) store_ = {
>>> (std::*fbstring_core*::(anonymous union)) = {
>>> (char [24]) small_ = "www"
>>> (std::fbstring_core::MediumLarge) ml_ = {
>>> (char *) data_ = 0x0077
>>> "H\x89U\xa8H\x89M\xa0L\x89E\x98H\x8bE\xa8H\x89��_U��D\x88e�H\x8bE\xa0H\x89��]U��H\x89�H\x8dE�H\x89�H\x89���
>>> ��L\x8dm�H\x8bE\x98H\x89��IU��\x88]�L\x8be\xb0L\x89��
>>> (std::size_t) size_ = 0
>>> (std::size_t) capacity_ = 1441151880758558720
>>> }
>>> }
>>> }
>>> }
>>>
>>>
>>> Admittedly, this is going to be a little vague since I haven’t really
>>> seen your code and I am only working off of one sample
>>>
>>> There’s going to be two parts to getting this to work:
>>>
>>> *Part 1 - Formatting fbstring_core*
>>>
>>> At a glance, an fbstring_core can be backed by two
>>> representations. A “small” representation (a char array), and a
>>> “medium/large" representation (a char* + a size)
>>> I assume that the way you tell one from the o
Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description
> 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
by design that it is not an easily accessible building block
> 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 of the concern is
> side-effect(the inferior method may throw exception or cause problems) but I
> would not see why this can't be done.
Because, as you say, it has a high risk of side effects
Also, it is less efficient than direct memory reads (I have a comparison graph
somewhere where some data formatter became an order of magnitude faster once it
stopped running code)
Also, what happens when your object is in scope but not yet initialized, or
you’re stopped in its destructor and it’s partially torn down? Are you going to
make all your methods able to deal safely with states that should never happen
in production because you might actually run into them in the debugger?
> By allowing this we can keep the data formatter truth one copy(in source
> code) instead of potential out-of-sync(let say the std::string author decided
> to change it implementation, the python data formatter associated with it
> needs to be modified at the same time which is a maintain nightmare).
The model you’re describing is similar to the “po” model we have in ObjC and
Swift. Those languages provide a sanctioned language-blessed way to create an
object description in program code (see -description for ObjC, and the whole
Mirror story for Swift)
Those are OK because they are only triggered by explicit user action (running
the “po” command in the debugger), and yet we still occasionally see problems
with them where the user didn’t realize the program state was corrupt enough
that running code there was a bad idea
C++ has no such sanctioned mechanism to generate descriptions - if one came
about, LLDB would support it, in the form of making “po” do the right thing for
C++ objects
> Jeffrey
>
>> On Thu, Apr 7, 2016 at 10:33 AM, Enrico Granata wrote:
>>
>>> 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 the data structure, lldb can parse the
>>> xml/json and deduce the formatting. This is approach used by data
>>> visualizer in VS debugger:
>>> https://msdn.microsoft.com/en-us/library/jj620914.aspx
>>> This will make adding data formatter more extensible/flexible. Any reason
>>> we did not take this approach?
>>
>> The way I understand the Natvis system, it allows one to provide a bunch of
>> expressions that describe how the debugger would go about retrieving the
>> interesting data bits
>> This has the bonus of being really easy, since you’re writing code in the
>> same language/context of the types you’re formatting
>> On the other hand it has a few drawbacks, in terms of performance as well as
>> safety (imagine trying to run code on an object when said object is in an
>> incoherent state)
>> The LLDB approach, on the other hand, is that you should try to not run code
>> when providing these data formatters. In order to do that, we vend an API
>> that can do things such as retrieve child values, read memory, cast values,
>> …, all without code execution
>> Once you have this kind of API that is not expressed in your source
>> language, you might just as well describe it in a scripting language. Hence
>> were born the Python data formatters.
>> In order for us to gain even more performance for native system types that
>> we know we’re gonna run into all the time, we then switched a bunch of the
>> “mission critical” formatters from Python to C++
>> The Python extension points are still available, as Jim pointed out, and you
>> are more than welcome to use those instead of modifying the debugger core
>>
>>> Jeffrey
>>>
On Wed, Apr 6, 2016 at 11:49 AM, Enrico Granata wrote:
> 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 variable corpus -T
> (const string &const) corpus = error: summary string parsing error: {
> (std::fbstring_core) store_ = {
> (std::fbstring_core::(anonymous union)) = {
> (char [24]) small_ = "www"
> (std::fbstring_co
Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description
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 thing. You
would want to at least use the expression path - and even then there are some
cases where we can't cons up a proper expression path.
Sent from my iPhone
> On Apr 13, 2016, at 11:02 AM, Jeffrey Tan wrote:
>
> 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()
> summaryValue = valobj.GetFrame().EvaluateExpression(valobj.name +
> '.c_str()')
> print "summaryValue: %s" % summaryValue
> return 'Summary from c_str(): %s ' % summaryValue.GetSummary()
>
> type summary add -F DoTest -x "std::fbstring_core"
>
> Output:
> valobj.GetFrame(): No value
> summaryValue: No value
> valobj: (std::string) $6 = {
> store_ = Summary from c_str(): None
> }
>
> Jeffrey
>
>> On Wed, Apr 13, 2016 at 10:11 AM, Jeffrey Tan
>> wrote:
>> 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
>> of the concern is side-effect(the inferior method may throw exception or
>> cause problems) but I would not see why this can't be done. By allowing this
>> we can keep the data formatter truth one copy(in source code) instead of
>> potential out-of-sync(let say the std::string author decided to change it
>> implementation, the python data formatter associated with it needs to be
>> modified at the same time which is a maintain nightmare).
>>
>> Jeffrey
>>
>>> On Thu, Apr 7, 2016 at 10:33 AM, Enrico Granata wrote:
>>>
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 the data structure, lldb can parse the
xml/json and deduce the formatting. This is approach used by data
visualizer in VS debugger:
https://msdn.microsoft.com/en-us/library/jj620914.aspx
This will make adding data formatter more extensible/flexible. Any reason
we did not take this approach?
>>>
>>> The way I understand the Natvis system, it allows one to provide a bunch of
>>> expressions that describe how the debugger would go about retrieving the
>>> interesting data bits
>>> This has the bonus of being really easy, since you’re writing code in the
>>> same language/context of the types you’re formatting
>>> On the other hand it has a few drawbacks, in terms of performance as well
>>> as safety (imagine trying to run code on an object when said object is in
>>> an incoherent state)
>>> The LLDB approach, on the other hand, is that you should try to not run
>>> code when providing these data formatters. In order to do that, we vend an
>>> API that can do things such as retrieve child values, read memory, cast
>>> values, …, all without code execution
>>> Once you have this kind of API that is not expressed in your source
>>> language, you might just as well describe it in a scripting language. Hence
>>> were born the Python data formatters.
>>> In order for us to gain even more performance for native system types that
>>> we know we’re gonna run into all the time, we then switched a bunch of the
>>> “mission critical” formatters from Python to C++
>>> The Python extension points are still available, as Jim pointed out, and
>>> you are more than welcome to use those instead of modifying the debugger
>>> core
>>>
Jeffrey
> On Wed, Apr 6, 2016 at 11:49 AM, Enrico Granata
> wrote:
>
>> 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 variable corpus -T
>> (const string &const) corpus = error: summary string parsing error: {
>> (std::fbstring_core) store_ = {
>> (std::fbstring_core::(anonymous union)) = {
>> (char [24]) small_ = "www"
>> (std::fbstring_core::MediumLarge) ml_ = {
>> (char *) data_ = 0x0077
>> "H\x89U\xa8H\x89M\xa0L\x89E\x98H\x8bE\xa8H
