[lldb-dev] [Bug 25011] New: Missing libxml/parser.h header on OS X 10.11 SDK
https://llvm.org/bugs/show_bug.cgi?id=25011
Bug ID: 25011
Summary: Missing libxml/parser.h header on OS X 10.11 SDK
Product: lldb
Version: 3.7
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: k06...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
Just tried to compile lldb-core on OS X 10.11 SDK and got error:
./lldb/llvm/tools/clang/tools/c-index-test/c-index-test.c:15:10: fatal error:
'libxml/parser.h' file not found
This file really does not exists nor in '/usr/include/libxml2' prepath nor
'${SDK_DIR}/usr/include/libxml2'.
--
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 25017] New: Alow image lookup -t to display detailed record layout
https://llvm.org/bugs/show_bug.cgi?id=25017 Bug ID: 25017 Summary: Alow image lookup -t to display detailed record layout Product: lldb Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: ztur...@google.com CC: llvm-b...@lists.llvm.org Classification: Unclassified Currently it only displays basic information about a type like its size, but it won't show you the offsets of individual fields, and it won't show you how virtual bases or virtual function table pointers are laid out in relation to the fields. We should add this as a feature. -- 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 25011] Missing libxml/parser.h header on OS X 10.11 SDK
https://llvm.org/bugs/show_bug.cgi?id=25011 Todd Fiala changed: What|Removed |Added Component|All Bugs|-New Bugs Assignee|lldb-dev@lists.llvm.org |unassignedclangbugs@nondot. ||org Product|lldb|clang --- Comment #2 from Todd Fiala --- (pushing it over to clang --- clang folks, feel free to pass back if this is somehow a misconfiguration on the lldb side. Might be clang-tools-extra but I'm not sure what goes there exactly). -- 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] Reminder, monthly bay-area LLVM social is today at 7pm!
The plan is as always: 7pm, The Tied House, Mountain View Meetup link: http://www.meetup.com/LLVM-Bay-Area-Social/events/224479893/ See folks there! -Chandler PS: sorry for not sending an email at the start of th eweek, will try to do that more regularly. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 25019] New: race in process return code collection in python test runner
https://llvm.org/bugs/show_bug.cgi?id=25019 Bug ID: 25019 Summary: race in process return code collection in python test runner Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified I have noticed that roughly 1 in 5 times, one of the process control child process return code tests is failing. It is receiving a 0 return code from the process that was definitely returning a 10 value (verified in multiple ways). This looks like it maybe similar to what was posted here: http://stackoverflow.com/questions/31539749/python-subprocess-read-returncode-is-sometimes-different-from-returned-code It looks like the root of it is that subprocess.Popen.communicate() indirectly sets the return code, and wait() does as well. And the mechanism by which this happens is not thread safe. Since this code is happening in two different threads of execution (intentionally), this is going to be problematic. I had initially torn out the communicate() call and replaced it with an asyncore loop, which we can easily work in our own poll() check to manage lifetime of the process. There's a simple state flow that needs to happen here. I yanked that out since we didn't have the asyncore.file_dispatcher on the Windows side. I think we may need a simple stdout/stderr pipe pump that essentially does what asyncore did, in a pure-python manner, so that we can make sure poll() happens in a thread-safe manner. -- 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 25019] race in process return code collection in python test runner
https://llvm.org/bugs/show_bug.cgi?id=25019 Todd Fiala changed: What|Removed |Added Assignee|lldb-dev@lists.llvm.org |todd.fi...@gmail.com -- 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
