Re: [lldb-dev] Green Dragon LLDB Xcode build update: TSAN support
On 6 April 2016 at 06:23, Todd Fiala wrote: > Okay, thanks all. > > FWIW I am running them on the OS X side. I haven't seen any stability > problems yet. I'd also expect them to be very stable, much more like a > compiler test, since there are far fewer parts in a small-scoped C++ unit > test (vs., say, our Python tests which are end-to-end and have many moving > parts). I've been running them locally, and I haven't noticed any flakyness. It should be also be much easier to remove it, if we find any, because of the smaller scope and number of tests. > > We've talked about it a bit over here, which I think you're alluding to, > which is how do we handle them assuming they were treated like any other > test (i.e. revert or fix fast if they break). That implies we need to run > them, which means we should make that easy. (Particularly easy to not > forget). On the OS X side we currently have a target and scheme that will > build and run them, but it's a separate target. I haven't done anything on > the Linux side to make that run, although plugging it into the test targets > shouldn't be hard. In cmake, you can run these tests with the check-lldb-unit target. I like the idea of being able to run both, but I think we should also keep the option of running them separately. How about: check-lldb: runs unit and python tests check-lldb-unit: runs unit tests only check-lldb-XXX: runs only python tests (for some value of XXX) > > I don't think the gtests replace the purpose of our Python tests, but I > think there's a wide-open place for them, particularly when initially > testing new classes or hard-to-expose places that would be overly cumbersome > to test (and therefore don't get tested). +1 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 27237] New: Cannot link lldb-server on a i386 system
https://llvm.org/bugs/show_bug.cgi?id=27237 Bug ID: 27237 Summary: Cannot link lldb-server on a i386 system Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: sylves...@debian.org CC: llvm-b...@lists.llvm.org Classification: Unclassified Looks like we are using too much memory during the link for a i386 system : cd "/tmp/buildd/llvm-toolchain-snapshot-3.9~svn265476/build-llvm/tools/lldb/tools/lldb-server" && /tmp/cmake/bin/cmake -E cmake_symlink_executable ../../../../bin/lldb-server-3.9.0 ../../../../bin/lldb-server make[4]: Leaving directory `/tmp/buildd/llvm-toolchain-snapshot-3.9~svn265476/build-llvm' [ 98%] Built target lldb-server /usr/bin/ld: final link failed: Memory exhausted collect2: error: ld returned 1 exit status make[4]: *** [lib/liblldb-3.9.so.1] Error 1 -- 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
[lldb-dev] [Bug 27238] New: Python API: Unable to detach a process in running state.
https://llvm.org/bugs/show_bug.cgi?id=27238 Bug ID: 27238 Summary: Python API: Unable to detach a process in running state. Product: lldb Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: release blocker Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: alexis.kof...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified The following code used to work before xcode 7.3 lldb-350.0.21.3. Now it seems that the process can't be detached anymore. There is no error, it just hangs when trying to detach and never execute the os._exit(0). Any thought ? safequit_command(debugger, command, result, internal_dict): process = lldb.target.process listener = debugger.GetListener() listener.StartListeningForEvents(process.GetBroadcaster(), lldb.SBProcess.eBroadcastBitStateChanged | lldb.SBProcess.eBroadcastBitSTDOUT | lldb.SBProcess.eBroadcastBitSTDERR) event = lldb.SBEvent() while True: if listener.WaitForEvent(1, event) and lldb.SBProcess.EventIsProcessEvent(event): state = lldb.SBProcess.GetStateFromEvent(event) else: state = process.GetState() if state == lldb.eStateRunning: process.Detach() os._exit(0) elif state > lldb.eStateRunning: os._exit(state) -- 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
[lldb-dev] [Bug 27247] New: ObjectFileELF should parse ".ARM" section headers to help determine the triple for ARM ELF files
https://llvm.org/bugs/show_bug.cgi?id=27247 Bug ID: 27247 Summary: ObjectFileELF should parse ".ARM" section headers to help determine the triple for ARM ELF files Product: lldb Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: clayb...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified There are some sections described in the ARM ELF spec that contain extra information that can help us to correctly determine the variant of ARM core in sections like ".ARM.attributes". This is described in the ARM ELF spec: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf in section 4.3.6 Build Attributes. Seems like there is some good stuff that we can use in this section. I am posting this in case anyone that uses ARM ELF files can get to this before I can fix it. -- 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
[lldb-dev] April LLVM bay-area social is this Thursday!
We'll be at Tied House as usual, starting on Thursday the 7th at 7pm! If you can, help us plan and RSVP here: http://meetu.ps/2Wdwkm See everyone there! - George ___ 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
> 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,
and then delegates the StringPrinter to do the grunt work
StringPrinter is a nifty little tool - it can handle generating summaries for
different kinds of strings (UTF8? UTF16? we got it - is a \0 a terminator? what
quote character would you like? …) - you point it at some data, set up a few
options, and it will generate a printable representation for you - if your
string type is doing anything out of the ordinary, let’s talk - I am definitely
open to extending StringPrinter to handle even more magic
Part 2 - Teaching std::string that it can be backed by an fbstring_core
At the end of part 1, you’ll probably end up with a
FBStringCoreSummaryProvider() - now you need to teach LLDB about it
The obvious thing you could do would be to go in
CPlusPlusLanguage::GetFormatters() add a LoadFBStringFormatter(g_category) to
it - and then imitate - say - LoadLibCxxFormatters()
AddCXXSummary(cpp_category_sp,
lldb_private::formatters::FBStringCoreSummaryProvider, “fbstringcore summary
provider", ConstString(“std::fbstring_core<.+>"), stl_summary_flags, true);
That will work - but what you would see is:
> (const string &const) corpus = error: summary string parsing error: {
> (std::fbstring_core) store_ = “www"
You wanna do
(lldb) log enable lldb formatters
(lldb) frame variable -T corpus
It will list one or more typenames - the most specific one is the one you like
(e.g. for libc++ we get std::__1::string - this is how we tell ourselves this
is the std::string from libc++)
Once you find that typename, you’ll make a new formatter -
FBStringSummaryProvider() - and register that formatter with that very specific
typename
All that FBStringSummaryProvider() has to do is get the “store_” member
(ValueObject::GetChildMemberWithName() is your friend) - and pass it down to
FBStringCoreSummaryProvider()
I understand this may seem a little convoluted and arcane at first - but feel
free to ask more questions, and I’ll try to help out!
> Thanks.
> Jeffrey
>
> On Mon, Mar 28, 2016 at 11:38 AM, Enrico Granata > wrote:
> 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 recognize a typename, then they try to inspect the variable in
> order to grab a summary
> In your example, your std::string exposes a layout that we are not handling -
> hence we bail out of the formatter and we fall back to the raw view
>
> If you want pretty printing to work, you’ll need to write a data formatter
>
> There are a few avenues. The obvious easy one is to extend the existing
> std::string formatter to recognize your type’s internal layout.
> If one
[lldb-dev] [Bug 27256] New: lldb doesn't support powerpc64 ELFv1 function descriptors
https://llvm.org/bugs/show_bug.cgi?id=27256 Bug ID: 27256 Summary: lldb doesn't support powerpc64 ELFv1 function descriptors Product: lldb Version: unspecified Hardware: Macintosh OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: chmeeed...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified LLDB is nearly complete for powerpc, but powerpc64 support needs function descriptors to get proper symbol tracking. PowerPC64 doesn't use normal function pointers in ELFv1 (big-endian, little endian now uses ELFv2, which does use normal function pointers), but instead uses function descriptors. LLDB can't quite parse this correctly, so disassembly doesn't work quite right. This is one of the last pieces needed for supporting powerpc64. -- 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
[lldb-dev] [Bug 27257] New: Integer division expression not correctly evaluated
https://llvm.org/bugs/show_bug.cgi?id=27257
Bug ID: 27257
Summary: Integer division expression not correctly evaluated
Product: lldb
Version: 3.8
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: tgfb...@me.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
Created attachment 16180
--> https://llvm.org/bugs/attachment.cgi?id=16180&action=edit
output with logging enabled.
In lldb bundled with Xcode 7.3 and Swift 2.2 Release for Ubuntu 14.04, integer
division expression is not correctly evaluated.
When debugging the following code:
$ cat /tmp/a.cpp
#include
int main() {
int b = 800;
printf("%d\n", b);
return 0;
}
$ clang -o /tmp/x -g /tmp/a.cpp
, integer division in expr is not evaluated correctly, while floating point
division seems to be good:
$ lldb /tmp/x
(lldb) target create "/tmp/x"
Current executable set to '/tmp/x' (x86_64).
(lldb) b 4
Breakpoint 1: where = x`main + 29 at a.cpp:4, address = 0x00010f6d
(lldb) run
Process 46865 launched: '/tmp/x' (x86_64)
Process 46865 stopped
* thread #1: tid = 0x5e9061, 0x00010f6d x`main + 29 at a.cpp:4, queue =
'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00010f6d x`main + 29 at a.cpp:4
1 #include
2 int main() {
3 int b = 800;
-> 4 printf("%d\n", b);
5 return 0;
6 }
(lldb) p b / 1
(int) $0 = 0
(lldb) p b / 2
(int) $1 = 0
(lldb) p b / 6
(int) $2 = 1
(lldb) p b / 13
(int) $3 = 1
(lldb) p b / 4.0
(double) $4 = 200
--
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
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?
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, and then delegates the StringPrinter to do the grunt work
> StringPrinter is a nifty little tool - it can handle generating summaries
> for different kinds of strings (UTF8? UTF16? we got it - is a \0 a
> terminator? what quote character would you like? …) - you point it at some
> data, set up a few options, and it will generate a printable representation
> for you - if your string type is doing anything out of the ordinary, let’s
> talk - I am definitely open to extending StringPrinter to handle even more
> magic
>
> *Part 2 - Teaching std::string that it can be backed by an fbstring_core*
>
> At the end of part 1, you’ll probably end up with a
> FBStringCoreSummaryProvider() - now you need to teach LLDB about it
> The obvious thing you could do would be to go in CPlusPlusLanguage
> ::GetFormatters() add a LoadFBStringFormatter(g_category) to it - and
> then imitate - say - LoadLibCxxFormatters()
>
> AddCXXSummary(cpp_category_sp, lldb_private::formatters::
> FBStringCoreSummaryProvider, “fbstringcore summary provider", ConstString(
> “std::fbstring_core<.+>"), stl_summary_flags, true);
>
> That will work - but what you would see is:
>
> (const string &const) corpus = error: summary string parsing error: {
> (std::*fbstring_core*) store_ = “www"
>
>
> You wanna do
>
> (lldb) log enable lldb formatters
> (lldb) frame variable -T corpus
>
> It will list one or more typenames - the most specific one is the one you
> like (e.g. for libc++ we get std::__1::string - this is how we tell
> ourselves this is the std::string from libc++)
> Once you find that typename, you’ll make a new formatter -
> FBStringSummaryProvider() - and register that formatter with that very
> specific typename
>
> All that FBStringSummaryProvider() has to do is get the “store_” member
> (ValueObject::GetChildMemberWithName() is your friend) - and pass it down
> to FBStringCoreSummaryProvider()
>
>
> I understand this may seem a little convoluted and arcane at first - but
> feel free to ask more questions, and I’ll try to help out!
>
> Thanks.
> Jeffrey
>
> On Mon, Mar 28, 2016 at 11:38 AM, Enrico Granata
> wrote:
>
>> This is kind of orthogonal to your problem, but the reason why you are
>> not seeing the kind of simpli
