Re: [lldb-dev] Redundant six.py copy
On Sun, May 1, 2016 at 2:21 PM, Kamil Rytarowski via lldb-dev < lldb-dev@lists.llvm.org> wrote: > It has been noted that LLDB installs its own copy of six.py > (third_party/Python/module/six/six.py) that conflicts with a standalone > one lang/py-six (path in pkgsrc). > > Could we reuse an external version shipped with a system? Alternatively > are there plans to migrate to Python 3 and remove need for it? > > How to address this conflict cleanly? > LLDB should continue to ship its own copy of six.py. It's a single 900 line source file. Avoiding this duplication is not worth the headache of asking users to install dependencies. I can't imagine a world where checking in your own copy *wasn't* the intended distribution model for six.py. I'm sure LLDB would take patches to mitigate the namespace conflict. For example, LLDB could do something like "from lldbutils import six" instead of "import six", or we could avoid putting it on sys.path if we notice a system installation of six. ___ 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
"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->y",
and can treat pointers as arrays: "my_ptr[12]", and can do address of "&argc"
and deref pointers "*this". And the text given to "frame variable" can do all
of them "&m->a.b[12].c->q".
"p" will return a ValueObject subclass that is ValueObjectConstResult. Any
children will be of type ValueObjectConstResultChild. This has a copy of the
expression result stored in a buffer up in LLDB itself and also down in the
process itself. Each one of these result objects has a unique name like "$0",
"$1", etc. Since the value is also stored in the program memory, it can be
accessed by a subsequent expression.
"frame variable" will use a fully modifiable version of the ValueObject,
usually a ValueObjectVariable. And any children will be ValueObjectChild.
So there might be some bugs in the
ValueObjectConstResult/ValueObjectConstResultChild classes.
Let us know what you find.
Greg
> On Apr 30, 2016, at 1:14 PM, Jeffrey Tan wrote:
>
> 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 I use "fr v" command
> the "char[24]" object is summarized correctly, while "p" command fail to
> recognize it. I suspect "char32_t [] summary provider" may have failed in "p"
> case, but could not understand why.
>
> (lldb) p small
> folly_stl_string_formatter: $2 $2
> folly_fbstring_core: store_ $2.store_ [115L, 109L, 97L, 108L, 108L, 0L, 0L,
> 0L, 235L, 46L, 64L, 0L, 0L, 0L, 0L, 0L, 80L, 213L, 255L, 255L, 255L, 127L,
> 0L, 18L]
> category: 0
> obj: (char [24]) small_ = {
> [0] = 's'
> [1] = 'm'
> [2] = 'a'
> [3] = 'l'
> [4] = 'l'
> [5] = '\0'
> [6] = '\0'
> [7] = '\0'
> [8] = '\xeb'
> [9] = '.'
> [10] = '@'
> [11] = '\0'
> [12] = '\0'
> [13] = '\0'
> [14] = '\0'
> [15] = '\0'
> [16] = 'P'
> [17] = '\xd5'
> [18] = '\xff'
> [19] = '\xff'
> [20] = '\xff'
> [21] = '\x7f'
> [22] = '\0'
> [23] = '\x12'
> }, None, None
> (std::string) $2 = None
> (lldb) fr v small
> folly_stl_string_formatter: small small
> folly_fbstring_core: store_ small.store_ [115L, 109L, 97L, 108L, 108L, 0L,
> 0L, 0L, 235L, 46L, 64L, 0L, 0L, 0L, 0L, 0L, 80L, 213L, 255L, 255L, 255L,
> 127L, 0L, 18L]
> category: 0
> obj: (char [24]) small_ = "small", "small", None
> (std::string) small = "small"
>
> ===
>
> import lldb
> target_byte_order = lldb.target.GetByteOrder()
>
> def get_category_value(category_sbvalue, category_extract_mask):
> return category_sbvalue.unsigned & category_extract_mask
>
>
> def folly_stl_string_formatter(valobj, internal_dict):
> '''Type summary formatter for std::string implemented by folly
> fbstring_core.
> '''
> print 'folly_stl_string_formatter: %s %s' % (valobj.name, valobj.path)
> folly_fbstring_sbvalue = valobj.GetValueForExpressionPath('.store_')
> return folly_fbstring_core_formatter(folly_fbstring_sbvalue,
> internal_dict)
>
>
> def folly_fbstring_core_formatter(valobj, internal_dict):
> '''Type summary formatter for folly fbstring_core.
> Please refer to
> https://github.com/facebook/folly/blob/master/folly/FBString.h
> for implementation details.
> '''
> print 'folly_fbstring_core: %s %s %s' % (valobj.name, valobj.path,
> str(valobj.data.uint8s))
> capacity_sbvalue = valobj.GetValueForExpressionPath('.ml_.capacity_')
> category_extract_mask = 0x3 if target_byte_order == lldb.eByteOrderBig
> else \
> (0xC000 if capacity_sbvalue.size == 4 else 0xC000)
>
> class Category:
> Small = 0
> Medium = (0x2 if target_byte_order == lldb.eByteOrderBig else
> (0x8000 if capacity_sbvalue.size == 4 else
> 0x8000))
> Large = (0x2 if target_byte_order == lldb.eByteOrderBig else
> (0x4000 if capacity_sbvalue.size == 4 else
> 0x4000))
>
> category = get_category_value(capacity_sbvalue, category_extract_mask)
> print 'category: %s' % category
> if category == Category.Small:
> obj = valobj.GetValueForExpressionPath('.small_')
> print 'obj: %s, %s, %s' % (obj, obj.summary, obj.description)
> return valobj.GetValueForExpressionPath('.small_').GetSummary()
> else:
> assert category == Category.Medium or category == Category.Large, \
> 'Unknown category: %d' % category
> return valobj.GetValueForExpressionPath('.ml_.data_').GetSummary()
>
>
> def __lldb
[lldb-dev] Inquiry about breakpoints on demangled function names
I am currently working on a language plugin for lldb. I would like to be able to put a breakpoint on demangled function names, but even after demangling function names through my custom DWARF parser, lldb won't autocomplete on demangled names nor break on them. I though about modifiying the IndexPrivate method in Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp, but it does not seem to be the cleanest thing to do. Where would be the most appropriate place in the lldb source to incorporate demangled function names so breakpoints on them become possible? My own DWARF parser? DWARFCompileUnit? Elias Boutaleb ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Developing a Plugin to be loaded in LLDB from external shared libs
Hi everyone There has been previous discussions in this mailing list regarding *E**nabling Intel(R) Processor Trace collection in LLDB. A new APIs are being developed to be added to SB APIs that will provide raw traces (collected on lldb-server side). These APIs are Trace technology independent and hence can work for other Tracing technologies also. The decoding of the raw traces can be done outside LLDB. For details you can refer to the thread with the subject "Review of API and remote packets" started on March 31, 2016.* I am working on developing a Plugin that will use these new APIs to enable *Intel(R) Processor Trace technology and *collect raw trace data for the inferior being debugged by LLDB. The plugin will perform decoding on the trace data to present it as a meaningful information to the user of LLDB Debugger. I want to use this plugin through LLDB CLI. I have few questions regarding development of this plugin: 1. What is the best way to develop this plugin? Should it be done as shown in "examples/plugins/commands/fooplugin.cpp" ( i.e. a C++ based solution and using 'plugin load ' command) or should I go for Python based solution to add new commands using Python functions? 2. I am planning to upstream this developed plugin in LLDB public repository once the development is finished. Any user that wants to use *Intel(R) Processor Trace *will be able to do so by compiling this plugin and loading it via LLDB CLI as an external library. What should be the ideal location to place this plugin in LLDB repository? I could think of the 'tools' folder. - Abhishek ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Inquiry about breakpoints on demangled function names
Currently the DWARF provides two things for a mangled function in the accelerator tables: 1 - the function basename 2 - the full mangled name So for a C++ function like: a::b::c(int, float, char) The accelerator tables would contain "c", and "_ZN1a1b3fooEifc" that would point the the DWARF for this function. Now the user doesn't always type in the complete function name. They might type: (lldb) b b::c What we do in this case is chop the name up into "look for 'c'" and then "make sure any matches contain 'b::c'". So this is what currently happens. It is one place where we don't defer to the language plug-ins and allow each language plugin to chop up the string the user typed, so currently if your language doesn't use "::" as the separate for things that are in namespaces/modules/classes, then it might be doing the wrong thing. The Swift enabled LLDB on swift.org has some additional things where we chop up names a little differently since swift uses "." to separate things that are in namespaces/modules/classes (like "a.b.foo(Int, Float, Char)" and the mangling is different as well. For swift we would handle: (lldb) b b.c as "look for 'c'" and then "make sure any matches contain 'b.c'". Can you give some examples of your mangle named and how it would look when demangled? It might help me guide my response a little better. > On May 2, 2016, at 2:49 AM, E BOUTALEB via lldb-dev > wrote: > > I am currently working on a language plugin for lldb. > I would like to be able to put a breakpoint on demangled function names, but > even after demangling function names through my custom DWARF parser, lldb > won't autocomplete on demangled names nor break on them. > > I though about modifiying the IndexPrivate method in > Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp, but it does not seem to be the > cleanest thing to do. > > Where would be the most appropriate place in the lldb source to incorporate > demangled function names so breakpoints on them become possible? My own DWARF > parser? DWARFCompileUnit? > > Elias Boutaleb > > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Redundant six.py copy
On 02.05.2016 18:40, Reid Kleckner wrote: > On Sun, May 1, 2016 at 2:21 PM, Kamil Rytarowski via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: > > It has been noted that LLDB installs its own copy of six.py > (third_party/Python/module/six/six.py) that conflicts with a standalone > one lang/py-six (path in pkgsrc). > > Could we reuse an external version shipped with a system? Alternatively > are there plans to migrate to Python 3 and remove need for it? > > How to address this conflict cleanly? > > > LLDB should continue to ship its own copy of six.py. It's a single 900 > line source file. Avoiding this duplication is not worth the headache of > asking users to install dependencies. I can't imagine a world where > checking in your own copy *wasn't* the intended distribution model for > six.py. > I don't agree here, built in libraries have security and maintainability issues downstream. Correct packaging is about removing these builtin redundant libraries and link with upstream ones. And in case of a vulnerability (or other kind of bug) upgrade a dependency for everybody at once. > I'm sure LLDB would take patches to mitigate the namespace conflict. For > example, LLDB could do something like "from lldbutils import six" > instead of "import six", or we could avoid putting it on sys.path if we > notice a system installation of six. Dynamic detection of system capabilities isn't reproducible. Also there is a scenario of installing lldb and later one of other packages installing global py-six. signature.asc Description: OpenPGP digital signature ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Redundant six.py copy
This may be true, but telling my users "you have to install six" is a non-starter. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > -Original Message- > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Kamil > Rytarowski via lldb-dev > Sent: Monday, May 02, 2016 4:36 PM > To: Reid Kleckner > Cc: LLDB > Subject: Re: [lldb-dev] Redundant six.py copy > > > > On 02.05.2016 18:40, Reid Kleckner wrote: > > On Sun, May 1, 2016 at 2:21 PM, Kamil Rytarowski via lldb-dev > > mailto:lldb-dev@lists.llvm.org>> wrote: > > > > It has been noted that LLDB installs its own copy of six.py > > (third_party/Python/module/six/six.py) that conflicts with a > standalone > > one lang/py-six (path in pkgsrc). > > > > Could we reuse an external version shipped with a system? > Alternatively > > are there plans to migrate to Python 3 and remove need for it? > > > > How to address this conflict cleanly? > > > > > > LLDB should continue to ship its own copy of six.py. It's a single 900 > > line source file. Avoiding this duplication is not worth the headache > > of asking users to install dependencies. I can't imagine a world where > > checking in your own copy *wasn't* the intended distribution model for > > six.py. > > > > I don't agree here, built in libraries have security and maintainability > issues > downstream. Correct packaging is about removing these builtin redundant > libraries and link with upstream ones. And in case of a vulnerability (or > other > kind of bug) upgrade a dependency for everybody at once. > > > I'm sure LLDB would take patches to mitigate the namespace conflict. > > For example, LLDB could do something like "from lldbutils import six" > > instead of "import six", or we could avoid putting it on sys.path if > > we notice a system installation of six. > > Dynamic detection of system capabilities isn't reproducible. Also there is a > scenario of installing lldb and later one of other packages installing global > py- > six. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Redundant six.py copy
Can we take care of this with python include path ordering? If we are on a system that has its own six.py somewhere in the python libraries, how is it picking our version incorrectly? Aren't there search paths for the modules? If so, we might need to put any compatibility modules into a specific directory and add that to the python search paths as the last path so it would always pick up any system versions or installed versions first, then fall back to our extra ones in our directories. Greg > On May 2, 2016, at 4:08 PM, Ted Woodward via lldb-dev > wrote: > > This may be true, but telling my users "you have to install six" is a > non-starter. > > -- > Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > >> -Original Message- >> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Kamil >> Rytarowski via lldb-dev >> Sent: Monday, May 02, 2016 4:36 PM >> To: Reid Kleckner >> Cc: LLDB >> Subject: Re: [lldb-dev] Redundant six.py copy >> >> >> >> On 02.05.2016 18:40, Reid Kleckner wrote: >>> On Sun, May 1, 2016 at 2:21 PM, Kamil Rytarowski via lldb-dev >>> mailto:lldb-dev@lists.llvm.org>> wrote: >>> >>>It has been noted that LLDB installs its own copy of six.py >>>(third_party/Python/module/six/six.py) that conflicts with a >> standalone >>>one lang/py-six (path in pkgsrc). >>> >>>Could we reuse an external version shipped with a system? >> Alternatively >>>are there plans to migrate to Python 3 and remove need for it? >>> >>>How to address this conflict cleanly? >>> >>> >>> LLDB should continue to ship its own copy of six.py. It's a single 900 >>> line source file. Avoiding this duplication is not worth the headache >>> of asking users to install dependencies. I can't imagine a world where >>> checking in your own copy *wasn't* the intended distribution model for >>> six.py. >>> >> >> I don't agree here, built in libraries have security and maintainability >> issues >> downstream. Correct packaging is about removing these builtin redundant >> libraries and link with upstream ones. And in case of a vulnerability (or >> other >> kind of bug) upgrade a dependency for everybody at once. >> >>> I'm sure LLDB would take patches to mitigate the namespace conflict. >>> For example, LLDB could do something like "from lldbutils import six" >>> instead of "import six", or we could avoid putting it on sys.path if >>> we notice a system installation of six. >> >> Dynamic detection of system capabilities isn't reproducible. Also there is a >> scenario of installing lldb and later one of other packages installing >> global py- >> six. > > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Redundant six.py copy
Having private fallback six.py will work for everybody, just it cannot be installed into the global path along with Python libraries: $ pkg_info -L lldb|grep six.py /usr/pkg/lib/python2.7/site-packages/six.py Maybe in lldb/utils/? chieftec$ pkg_info -L lldb|grep py /usr/pkg/lib/python2.7/site-packages/lldb/__init__.py /usr/pkg/lib/python2.7/site-packages/lldb/_lldb.so /usr/pkg/lib/python2.7/site-packages/lldb/embedded_interpreter.py /usr/pkg/lib/python2.7/site-packages/lldb/formatters/Logger.py /usr/pkg/lib/python2.7/site-packages/lldb/formatters/__init__.py /usr/pkg/lib/python2.7/site-packages/lldb/formatters/attrib_fromdict.py /usr/pkg/lib/python2.7/site-packages/lldb/formatters/cache.py /usr/pkg/lib/python2.7/site-packages/lldb/formatters/cpp/__init__.py /usr/pkg/lib/python2.7/site-packages/lldb/formatters/cpp/gnu_libstdcpp.py /usr/pkg/lib/python2.7/site-packages/lldb/formatters/cpp/libcxx.py /usr/pkg/lib/python2.7/site-packages/lldb/formatters/metrics.py /usr/pkg/lib/python2.7/site-packages/lldb/lldb-argdumper /usr/pkg/lib/python2.7/site-packages/lldb/runtime/__init__.py /usr/pkg/lib/python2.7/site-packages/lldb/utils/__init__.py /usr/pkg/lib/python2.7/site-packages/lldb/utils/symbolication.py /usr/pkg/lib/python2.7/site-packages/six.py On 03.05.2016 02:13, Greg Clayton via lldb-dev wrote: > Can we take care of this with python include path ordering? If we are on a > system that has its own six.py somewhere in the python libraries, how is it > picking our version incorrectly? Aren't there search paths for the modules? > If so, we might need to put any compatibility modules into a specific > directory and add that to the python search paths as the last path so it > would always pick up any system versions or installed versions first, then > fall back to our extra ones in our directories. > > Greg > >> On May 2, 2016, at 4:08 PM, Ted Woodward via lldb-dev >> wrote: >> >> This may be true, but telling my users "you have to install six" is a >> non-starter. >> >> -- >> Qualcomm Innovation Center, Inc. >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a >> Linux Foundation Collaborative Project >> >>> -Original Message- >>> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Kamil >>> Rytarowski via lldb-dev >>> Sent: Monday, May 02, 2016 4:36 PM >>> To: Reid Kleckner >>> Cc: LLDB >>> Subject: Re: [lldb-dev] Redundant six.py copy >>> >>> >>> >>> On 02.05.2016 18:40, Reid Kleckner wrote: On Sun, May 1, 2016 at 2:21 PM, Kamil Rytarowski via lldb-dev mailto:lldb-dev@lists.llvm.org>> wrote: It has been noted that LLDB installs its own copy of six.py (third_party/Python/module/six/six.py) that conflicts with a >>> standalone one lang/py-six (path in pkgsrc). Could we reuse an external version shipped with a system? >>> Alternatively are there plans to migrate to Python 3 and remove need for it? How to address this conflict cleanly? LLDB should continue to ship its own copy of six.py. It's a single 900 line source file. Avoiding this duplication is not worth the headache of asking users to install dependencies. I can't imagine a world where checking in your own copy *wasn't* the intended distribution model for six.py. >>> >>> I don't agree here, built in libraries have security and maintainability >>> issues >>> downstream. Correct packaging is about removing these builtin redundant >>> libraries and link with upstream ones. And in case of a vulnerability (or >>> other >>> kind of bug) upgrade a dependency for everybody at once. >>> I'm sure LLDB would take patches to mitigate the namespace conflict. For example, LLDB could do something like "from lldbutils import six" instead of "import six", or we could avoid putting it on sys.path if we notice a system installation of six. >>> >>> Dynamic detection of system capabilities isn't reproducible. Also there is a >>> scenario of installing lldb and later one of other packages installing >>> global py- >>> six. >> >> >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > signature.asc Description: OpenPGP digital signature ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] May LLVM bay-area social is this Thursday!
We'll be at Tied House as usual, starting on Thursday the 5th at 7pm! If you can, please help us plan and RSVP here: http://meetu.ps/2Wj7Tc See everyone there! George ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
