[lldb-dev] [Bug 25346] New: Python/C++ binding SBTarget.LaunchSimple does not disable ASLR

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25346

Bug ID: 25346
   Summary: Python/C++ binding SBTarget.LaunchSimple does not
disable ASLR
   Product: lldb
   Version: unspecified
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: felber.jonas+l...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

more on
http://stackoverflow.com/questions/33394623/lldb-python-c-binding-set-breakpoint-at-pic-addr

[~]$ lldb --version
lldb-340.4.110

-- 
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 23560] lldb does not understand gcc-4.9 function prologues

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=23560

abhiinnit...@gmail.com changed:

   What|Removed |Added

 CC||abhiinnit...@gmail.com
   Assignee|lldb-dev@lists.llvm.org |abhiinnit...@gmail.com

--- Comment #1 from abhiinnit...@gmail.com ---
I'm working on it. I will submit a fix soon.

-- 
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 23139] Some tests fail with gcc-4.9.2 on Linux

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=23139

abhiinnit...@gmail.com changed:

   What|Removed |Added

 CC||abhiinnit...@gmail.com
   Assignee|lldb-dev@lists.llvm.org |abhiinnit...@gmail.com

--- Comment #1 from abhiinnit...@gmail.com ---
I am working on it. Hope to submit a fix for 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] [Bug 23139] Some tests fail with gcc-4.9.2 on Linux

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=23139

abhiinnit...@gmail.com changed:

   What|Removed |Added

 CC||lldb-dev@lists.llvm.org

-- 
You are receiving this mail because:
You are on the CC list 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 23560] lldb does not understand gcc-4.9 function prologues

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=23560

abhiinnit...@gmail.com changed:

   What|Removed |Added

 CC||lldb-dev@lists.llvm.org

-- 
You are receiving this mail because:
You are on the CC list 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 25396] New: Unclear error message when loading PE executable on OS X

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25396

Bug ID: 25396
   Summary: Unclear error message when loading PE executable on OS
X
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: whitequ...@whitequark.org
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

lldb currently says: "error: the platform is not currently connected".

This could be improved.

-- 
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 22875] unwind-on-error-in-expressions=false is broken

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=22875

Keno Fischer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kfisc...@college.harvard.ed
   ||u
 Resolution|--- |FIXED

--- Comment #1 from Keno Fischer  ---
Fixed in Clang by r252229.

-- 
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 25433] New: LLDB expressions confused by overloading

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25433

Bug ID: 25433
   Summary: LLDB expressions confused by overloading
   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: ai...@codeplay.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 15235
  --> https://llvm.org/bugs/attachment.cgi?id=15235&action=edit
Test case for lldbs testsuite to reproduce this problem.

If a function is inconsistently overloaded and both mangled and unmangled
versions are exported, it is possible that the expression parser will become
confused and will call any of them, regardless of the function arguments.  This
could cause an expression, which calling a function like this to segfault the
target.

A test case is attached that will run as part of the lldb test suite which will
reproduce this problem.

Details of this problem were emailed to the lldb mailing list on the 5th nov
2015.


The test case is setup as follows:
I have one shared library, liba.so which exports a C function:
int foo(float* v);

I have another shared library, libb.so, which exports two functions with the
overloaded attribute:
int __attribute__((overloadable)) foo(float* f);
int __attribute__((overloadable)) foo(int* f2);


Additionaly, liba.so should be compiled without any debugging information,
however libb.so can be compiled with debug info.


I have a main executable which is linked against both of these shared
libraries.
If I try to call foo(int* f2) by passing in an int pointer as parameter, it
will instead incorrectly execute the float version.


Further more, if libb.so containst debug info, on one target I have seen lldb
execute which ever version of the function it can find that has dwarf info
associated with it.
It seems inconsistent as to wether the test case exhibits this additional
behaviour, however farther effort will be put into pinning this down.


I think there is a case to be made for first trying to mangle the function the
expression is calling and searching for that and as a fall back checking for
the presence of the unmangled version.
I belive this should correct this problem.

-- 
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] [BUG] Regression: unprintable characters displayed

[via lldb-dev]

On Tue, Oct 20, 2015 at 04:09:16PM -0400, Ramkumar Ramachandra via lldb-dev 
wrote:
> Hi,
> 
> This does not happen with lldb-330.0.48, which ships with OS X, but
> happens with HEAD:
> 
> frame #0: 0x000101c3ce8c libmwcgir_vm_rt.dylib`(anonymous
> namespace)::CgJITMemManager::endFunctionBody(this=0x00010a715610,
> F=0x00010a6da200, FunctionStart="^\n\x01",
> FunctionEnd="??...

Can you provide a test case, steps, and expected results please?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 25446] New: lldb Python extension module is linked to libpython

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25446

Bug ID: 25446
   Summary: lldb Python extension module is linked to libpython
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: l...@tim-smith.us
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Hi; I'm a maintainer of Homebrew, a package manager for OS X. We package and
distribute LLVM. LLDB builds an import-able Python module which lands in
lib/python2.7/site-packages/lldb/_lldb.so. When LLVM and LLDB are built using
the cmake build (and possibly otherwise), this module is explicitly linked
against a Python framework, and it should not be, because that prevents the
module from being imported by a compatible interpreter located somewhere else
on the system. An attempt to do so will result in segfaults. This is
unnecessary and makes the module harder to distribute. The module should be
built with -undefined dynamic_lookup instead of -lpython.

Please see this blog post for more background:
http://blog.tim-smith.us/2015/09/python-extension-modules-os-x/

Running otool -L against the module shows that it has an explicit link to a
Python framework:

tim@rocketman:~$ otool -L
/usr/local/Cellar/llvm/3.6.2/lib/python2.7/site-packages/lldb/_lldb.so
/usr/local/Cellar/llvm/3.6.2/lib/python2.7/site-packages/lldb/_lldb.so:
...
/System/Library/Frameworks/Python.framework/Versions/2.7/Python
(compatibility version 2.7.0, current version 2.7.10)

Extension modules should not show this linkage.

This Homebrew bug is related: https://github.com/Homebrew/homebrew/pull/45787

-- 
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 25158] lldb fails to identify Linux OS for many shared objects

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25158

Todd Fiala  changed:

   What|Removed |Added

   Assignee|todd.fi...@gmail.com|lldb-dev@lists.llvm.org

-- 
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 25450] Convert standard concurrent test runner output over to TestResult-based implementation

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25450

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

[lldb-dev] [Bug 25450] New: Convert standard concurrent test runner output over to TestResult-based implementation

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25450

Bug ID: 25450
   Summary: Convert standard concurrent test runner output over to
TestResult-based implementation
   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

A few months back I added the TestResults and test_event infrastructure to the
concurrent test runner.

It's time to covert our standard text-based (non-curses) output over to use
this infrastructure.  In the process, we'll get more accurate information about
number of tests runs and test-method-based counts (rather than test class or
test file-based counts, which are less interesting).

Once the following feature is implemented:
https://llvm.org/bugs/show_bug.cgi?id=24828

We'll also be able to note test methods that failed to run (possibly due to an
inferior detest.py timing out).  I'll file that as a separate bugzilla task,
though.

-- 
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 25451] New: Display test methods that didn't get a chance to run due to timeouts or other abnormal exits

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25451

Bug ID: 25451
   Summary: Display test methods that didn't get a chance to run
due to timeouts or other abnormal exits
   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

In the test suite, if a TIMEOUT or other inferior detest.py exit prevented all
test methods to be executed/evaluated, have the standard test results formatter
display the test methods that did not get evaluated (whether it be a run,
xfail, skip, etc.)

This depends on the following tasks being implemented first:
https://llvm.org/bugs/show_bug.cgi?id=25450
https://llvm.org/bugs/show_bug.cgi?id=24828

-- 
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 25451] Display test methods that didn't get a chance to run due to timeouts or other abnormal exits

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25451

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

[lldb-dev] [Bug 25300] Certain environment variables crash lldb-server

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25300

Tim Northover  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Tim Northover  ---
This should be fixed now (Jason's r252239 and my r252521). Thanks for reporting
it so carefully!

-- 
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 25468] New: SWIG wrappers fail to compile with "-Werror=format-security"

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25468

Bug ID: 25468
   Summary: SWIG wrappers fail to compile with
"-Werror=format-security"
   Product: lldb
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: axw...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

I'm trying to build Debian packages for LLVM+Clang+LLDB+compiler-rt locally,
and I'm getting an error building LLDB.




cd /home/andrew/code/src/llvm.org/llvm/build-llvm/tools/lldb/source/API &&
/usr/bin/g++-4.9   -DGTEST_HAS_RTTI=0 -DHAVE_PROCESS_VM_READV -DHAVE_ROUND
-DLIBXML2_DEFINED -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security  -fPIC -fvisibility-inlines-hidden -Wall -W
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wno-missing-field-initializers -pedantic -Wno-long-long
-Wno-maybe-uninitialized -Wno-comment -std=c++11 -Wno-deprecated-declarations
-Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register
-Wno-vla-extension  -fno-exceptions -fno-rtti -fPIC -fPIC -g -fPIC
-I/home/andrew/code/src/llvm.org/llvm/build-llvm/tools/lldb/source/API
-I/home/andrew/code/src/llvm.org/llvm/tools/lldb/source/API
-I/home/andrew/code/src/llvm.org/llvm/tools/lldb/include
-I/home/andrew/code/src/llvm.org/llvm/build-llvm/tools/lldb/include
-I/home/andrew/code/src/llvm.org/llvm/build-llvm/include
-I/home/andrew/code/src/llvm.org/llvm/include -I/usr/include/python2.7
-I/home/andrew/code/src/llvm.org/llvm/tools/clang/include
-I/home/andrew/code/src/llvm.org/llvm/build-llvm/tools/lldb/../clang/include
-I/usr/include/libxml2
-I/home/andrew/code/src/llvm.org/llvm/tools/lldb/source/.
-I/home/andrew/code/src/llvm.org/llvm/tools/lldb/source/Plugins/Process/Linux
-I/home/andrew/code/src/llvm.org/llvm/tools/lldb/source/Plugins/Process/POSIX  
  -fno-exceptions -fno-rtti  -Wno-sequence-point -Wno-cast-qual -o
CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o -c
/home/andrew/code/src/llvm.org/llvm/build-llvm/tools/lldb/scripts/LLDBWrapPython.cpp
/home/andrew/code/src/llvm.org/llvm/build-llvm/tools/lldb/scripts/LLDBWrapPython.cpp:
In function ‘PyObject*
_wrap_SBError_SetErrorStringWithFormat__SWIG_3(PyObject*, PyObject*)’:
/home/andrew/code/src/llvm.org/llvm/build-llvm/tools/lldb/scripts/LLDBWrapPython.cpp:21230:70:
error: format not a string literal and no format arguments
[-Werror=format-security]
 result = (int)(arg1)->SetErrorStringWithFormat((char const *)arg2);
  ^
At global scope:
cc1plus: warning: unrecognized command line option "-Wno-vla-extension"
cc1plus: warning: unrecognized command line option "-Wno-deprecated-register"
cc1plus: some warnings being treated as errors
tools/lldb/source/API/CMakeFiles/liblldb.dir/build.make:1414: recipe for target
'tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o'
failed

-- 
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 25470] New: TestMiInterpreterExec is flaky on linux

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25470

Bug ID: 25470
   Summary: TestMiInterpreterExec is flaky on linux
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

ERROR: test_lldbmi_thread_continue
(TestMiInterpreterExec.MiInterpreterExecTestCase)
   Test that 'lldb-mi --interpreter' can continue execution by "thread
continue" command.
--
Traceback (most recent call last):
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/tools/lldb-mi/interpreter/TestMiInterpreterExec.py",
line 227, in test_lldbmi_thread_continue
self.expect("@\"argc=1rn")
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/tools/lldb-mi/lldbmi_testcase.py",
line 54, in expect
return self.child.expect(pattern, *args, **kwargs)
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
line 1316, in expect
return self.expect_list(compiled_pattern_list, timeout, searchwindowsize)
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
line 1330, in expect_list
return self.expect_loop(searcher_re(pattern_list), timeout,
searchwindowsize)
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
line 1414, in expect_loop
raise TIMEOUT (str(e) + '\n' + str(self))
TIMEOUT: Timeout exceeded in read_nonblocking().

version: 2.4 ($Revision: 516 $)
command: /lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/lldb-mi
args: ['/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/lldb-mi',
'--interpreter']
searcher: searcher_re:
0: re.compile("@"argc=1\\r\\n")
buffer (last 100 chars): roup-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
(gdb)

before (last 100 chars): roup-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
(gdb)

-- 
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 25478] New: backtick syntax is undocumented (and interacts oddly with strings)

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25478

Bug ID: 25478
   Summary: backtick syntax is undocumented (and interacts oddly
with strings)
   Product: lldb
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: andi.m.mccl...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

I am running lldb-340.4.110.1 (obtained via XCode 7.1.1) at the command line on
Mac OS X. I type the innocuous expression:

break set -F the_function_name -condition '0 == (int)strcmp(str1,
"IDictionary`2") && 0 == (int)strcmp(str2, "IDictionary`2")'

I get the totally baffling set of errors:

error: error: invalid suffix on literal; C++11 requires a space between literal
and identifier
error: expected ';' after expression
error: expected ';' after expression
error: use of undeclared identifier 'IDictionary'
error: 4 errors parsing expression

I find if the condition is '0 == (int)strcmp(str1, "IDictionary`2")' only, it
works fine. 

Several days pass before I figure out what is happening here. A note in the
"GDB to LLDB command map" document explains:
"NOTE: any command can inline a scalar expression result (as long as the target
is stopped) using backticks around any expression"

Once I realize this, I try placing backslashes before the backticks in my
expression:

break set -F the_function_name -condition '0 == (int)strcmp(str1,
"IDictionary\`2") && 0 == (int)strcmp(str2, "IDictionary\`2")'

Now it works.

I see three problems here.

First off, my opinion is that this is not very good behavior. I don't expect
backtick evaluation or any kind of other string mutation to silently trigger
occur *inside* of a single-quoted string (crossing between two quoted strings,
in this case!). However, I can imagine that backtick evaluation inside a string
would probably be very useful for someone somewhere, so I will assume that this
is the intentional design of the feature.

Second off, I do not think this error was well reported. The important thing,
in my case, for deciphering the error message was to understand that the
backtick substitution feature was triggering at all. The error message did not
indicate that the "error" reported was from a backtick expression.

Third and most importantly, this feature and its behavior is undocumented.
Looking at the docs on lldb.llvm.org I find the backticks are mentioned only in
the GDB->LLDB transition guide, and there only parenthetically. The transition
guide is not a good place to introduce an entire feature, and worse, the
details of how the feature work are not described (that it works even inside of
a string, that it can be neutralized with a backtick).

Expected behavior: The lldb.llvm.org documentation should fully document the
backticks in the place where expression features would normally be documented
(I recommend the "COMMAND STRUCTURE" section of the tutorial). The
documentation should explain "when" the backticks are evaluated (i.e.: before
interpreting quote characters or anything else) and any quirks or
neutralization methods the backtick has, such as the backslash escape. (The
tutorial mentions backslash-escaping now, but the only characters mentioned are
double-quote and backslash). Finally, IMO, when you are printing an error
message related to a backtick expression, the error message should actually
begin with "error in backtick expression" or "error in backslash expression".

Thanks

-- 
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 25484] New: TestTerminal.LaunchInTerminalTestCase.test_launch_in_terminal failing on Darwin

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25484

Bug ID: 25484
   Summary: TestTerminal.LaunchInTerminalTestCase.test_launch_in_t
erminal failing on Darwin
   Product: lldb
   Version: unspecified
  Hardware: Macintosh
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

On OS X 10.11 (10.11.1 (15B42)), using the following build:

xcodebuild -scheme desktop -configuration Debug DEBUGSERVER_USE_FROM_SYSTEM=1

I have gotten a test failure on:

TestTerminal.LaunchInTerminalTestCase.test_launch_in_terminal

2 out of 2 times.

FAIL

 >>: success

Traceback (most recent call last):
  File
"/Users/tfiala/src/lldb/git-svn/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 508, in wrapper
return func(self, *args, **kwargs)
  File
"/Users/tfiala/src/lldb/git-svn/lldb/packages/Python/lldbsuite/test/functionalities/tty/TestTerminal.py",
line 37, in test_launch_in_terminal
self.assertTrue(error.Success(), "Make sure launch happened successfully in
a terminal window")
AssertionError: False is not True : Make sure launch happened successfully in a
terminal window
Config=x86_64-clang
Session info generated @ Tue Nov 10 19:33:34 2015
To rerun this test, issue the following command from the 'test' directory:

./dotest.py -A x86_64 -C clang -v -t  -f
LaunchInTerminalTestCase.test_launch_in_terminal

-- 
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 25485] New: TestCompletion.CommandLineCompletionTestCase.test_symbol_name_dwarf failing intermittently under load on Darwin

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25485

Bug ID: 25485
   Summary: TestCompletion.CommandLineCompletionTestCase.test_symb
ol_name_dwarf failing intermittently under load on
Darwin
   Product: lldb
   Version: unspecified
  Hardware: Macintosh
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

On OS X 10.11.2 Beta (15C31f),
TestCompletion.CommandLineCompletionTestCase.test_symbol_name_dwarf is failing
intermittently (2 out of 3 times on my system) when the parallel test runner is
used.

Test trace follows:

os command: make clean 
with pid: 48966
stdout: rm -f  main.o main.d main.d.tmp main.dwo   
rm -f -r "a.out.dSYM"
rm -f "a.out"

stderr: 
retcode: 0



os command: make MAKE_DSYM=NO ARCH=x86_64 CC="clang" 
with pid: 49028
stdout: clang++ -std=c++11 -g -O0 -fno-builtin -arch x86_64  
-I/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/make/../../../../../include
-include
/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/make/test_common.h
   -c -o main.o main.cpp
clang++  main.o -g -O0 -fno-builtin -arch x86_64  
-I/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/make/../../../../../include
-include
/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/make/test_common.h
   -o "a.out"

stderr: 
retcode: 0


looking at: (lldb) file a.out
Current executable set to 'a.out' (x86_64).
(lldb)  breakpoint set -n Fo
(lldb) 

Expecting sub string: breakpoint set -n Foo::Bar(int,\ int)
Not matched

FAIL

tearing down the child process

Traceback (most recent call last):
  File
"/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 536, in wrapper
return func(self, *args, **kwargs)
  File
"/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2228, in dwarf_test_method
return attrvalue(self)
  File
"/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 608, in wrapper
func(*args, **kwargs)
  File
"/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/functionalities/completion/TestCompletion.py",
line 262, in test_symbol_name
turn_off_re_match=True)
  File
"/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/functionalities/completion/TestCompletion.py",
line 320, in complete_from_to
substrs = [p])
  File
"/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2764, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : 'file a.out
 breakpoint set -n Fo' successfully completes
to 'breakpoint set -n Foo::Bar(int,\ int)'
Config=x86_64-clang
Session info generated @ Tue Nov 10 20:26:58 2015
To rerun this test, issue the following command from the 'test' directory:

./dotest.py -A x86_64 -C clang -v -t  -f
CommandLineCompletionTestCase.test_symbol_name_dwarf

-- 
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 25486] New: test_qRegisterInfo_returns_{one_valid_result, all_valid_results} fails under heavy load

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25486

Bug ID: 25486
   Summary: test_qRegisterInfo_returns_{one_valid_result,all_valid
_results} fails under heavy load
   Product: lldb
   Version: unspecified
  Hardware: Macintosh
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

Created attachment 15263
  --> https://llvm.org/bugs/attachment.cgi?id=15263&action=edit
Failure test client and debugserver logs

On OS X 10.11.2 Beta (15C31f), I'm seeing these failures:

TestLldbGdbServer.LldbGdbServerTestCase.test_qRegisterInfo_returns_all_valid_results
TestLldbGdbServer.LldbGdbServerTestCase.test_qRegisterInfo_returns_one_valid_result

I've attached the traces.

I will look into this.  I'll mark them XFAIL on Darwin until I figure out
what's up.

-- 
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 25486] test_qRegisterInfo_returns_{one_valid_result, all_valid_results} fails under heavy load

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25486

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

[lldb-dev] [Bug 25487] New: TestDataFormatterObjC.py times out under load on Darwin

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25487

Bug ID: 25487
   Summary: TestDataFormatterObjC.py times out under load on
Darwin
   Product: lldb
   Version: unspecified
  Hardware: Macintosh
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

On OS X 10.11.2 Beta (15C31f), I am seeing TestDataFormatterObjC.py TIMEOUT
after what looks like no progress is made at some point.  I am not able to get
this hang to occur when running it over and over in a no-load situation.

-- 
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 23560] lldb does not understand gcc-4.9 function prologues

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=23560

abhiinnit...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from abhiinnit...@gmail.com ---
This Bug is resolved by r253026.

-- 
You are receiving this mail because:
You are on the CC list 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 25562] New: Some failing tests are being reported as passes

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25562

Bug ID: 25562
   Summary: Some failing tests are being reported as passes
   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

If I run this test manually, two of the tests fails.  Example:

d:\src\llvmbuild\ninja\lldb-test-traces>c:\python27_lldb\x86\python_d.exe
D:\src\llvm\tools\lldb\test\dotest.py -q --arch=i686 --executable
D:/src/llvmbuild/ninja/bin/lldb.exe -s D:/src/llvmbuild/ninja/lldb-test-traces
-u CXXFLAGS -u CFLAGS --enable-crash-dialog -C
d:\src\llvmbuild\ninja_release\bin\clang.exe
D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\process_launch
--no-multiprocess
The 'lldb-mi' executable cannot be located.  The lldb-mi tests can not be run
as a result.
UNSUPPORTED: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) ::
test_environment_with_special_char_dsym
(TestProcessLaunch.ProcessLaunchTestCase) (dsym tests)
FAIL: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) ::
test_environment_with_special_char_dwarf
(TestProcessLaunch.ProcessLaunchTestCase)
FAIL: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) ::
test_environment_with_special_char_dwo
(TestProcessLaunch.ProcessLaunchTestCase)
UNSUPPORTED: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) ::
test_io_dsym (TestProcessLaunch.ProcessLaunchTestCase) (dsym tests)
PASS: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: test_io_dwarf
(TestProcessLaunch.ProcessLaunchTestCase)
PASS: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) :: test_io_dwo
(TestProcessLaunch.ProcessLaunchTestCase)
UNSUPPORTED: LLDB (d:\src\llvmbuild\ninja_release\bin\clang.exe-i686) ::
test_set_working_dir_dsym (TestProcessLaunch.ProcessLaunchTestCase) (dsym
tests)

When I run the multiprocess test runner via dosep, it's being reported as a
success.

410 out of 410 test suites processed - TestAddDsymCommand.py
Ran 410 test suites (1 failed) (0.243902%)
Ran 318 test cases (4 failed) (1.257862%)
Failing Tests (1)
FAIL: LLDB (suite) :: TestBreakpointLanguage.py (Windows zturner-win81 8
6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
[79964 refs]
ninja: build stopped: subcommand failed.

Stepping through the code, in dosep.py when it goes to print the summary list
of failed tests, 'TestProcessLaunch.py' is in the list of passed tests.  So
something is wrong here, and a potentially unknown number of tests are
currently being misreported.

-- 
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 25624] New: TestFdLeak fails on FreeBSD with Python 2.7.10

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25624

Bug ID: 25624
   Summary: TestFdLeak fails on FreeBSD with Python 2.7.10
   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

On both my (not yet connected) FreeBSD 11 buildbot and local FreeBSD 10 builds:

==
FAIL: test_fd_leak_basic_dwarf (TestFdLeak.AvoidsFdLeakTestCase)
--
Traceback (most recent call last):
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 564, in wrapper
return func(self, *args, **kwargs)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2297, in dwarf_test_method
return attrvalue(self)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 636, in wrapper
func(*args, **kwargs)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1216, in wrapper
func(*args, **kwargs)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py",
line 29, in test_fd_leak_basic
self.do_test([])
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py",
line 51, in do_test
"Process returned non-zero status. Were incorrect file descriptors
passed?")
AssertionError: False is not True : Process returned non-zero status. Were
incorrect file descriptors passed?
Config=x86_64-/usr/bin/cc

-- 
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 25625] New: TestCppIncompleteTypes failing on FreeBSD 11 buildbot

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25625

Bug ID: 25625
   Summary: TestCppIncompleteTypes failing on FreeBSD 11 buildbot
   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

On my FreeBSD 11 buildbot (not yet added to the build master):

==
FAIL: test_limit_debug_info_dwarf
(TestCppIncompleteTypes.TestCppIncompleteTypes)
--
Traceback (most recent call last):
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 564, in wrapper
return func(self, *args, **kwargs)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2297, in dwarf_test_method
return attrvalue(self)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1164, in wrapper
func(*args, **kwargs)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/cpp/incomplete-types/TestCppIncompleteTypes.py",
line 16, in test_limit_debug_info
self.assertFalse(value_f.GetError().Success(), "'expr f' results in an
error, but LLDB does not crash")
AssertionError: True is not False : 'expr f' results in an error, but LLDB does
not crash
Config=x86_64-/usr/bin/cc
==
FAIL: test_limit_debug_info_dwo (TestCppIncompleteTypes.TestCppIncompleteTypes)
--
Traceback (most recent call last):
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 578, in wrapper
return func(self, *args, **kwargs)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2306, in dwo_test_method
return attrvalue(self)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1164, in wrapper
func(*args, **kwargs)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/cpp/incomplete-types/TestCppIncompleteTypes.py",
line 16, in test_limit_debug_info
self.assertFalse(value_f.GetError().Success(), "'expr f' results in an
error, but LLDB does not crash")
AssertionError: True is not False : 'expr f' results in an error, but LLDB does
not crash
Config=x86_64-/usr/bin/cc
--
Ran 6 tests in 1.539s

-- 
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 25626] New: expectedFailureClang decorator may not work on FreeBSD

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25626

Bug ID: 25626
   Summary: expectedFailureClang decorator may not work on FreeBSD
   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

packages/Python/lldbsuite/test/lang/c/typedef/Testtypedef.py has

@dwarf_test
@expectedFailureClang("llvm.org/pr19238")
def test_with_dwarf(self):

but it reports failure on the in-progress FreeBSD 11 buildbot:

==
FAIL: test_with_dwarf_dwarf (Testtypedef.TypedefTestCase)
   Test 'image lookup -t a' and check for correct display at different scopes.
--
Traceback (most recent call last):
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 564, in wrapper
return func(self, *args, **kwargs)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2297, in dwarf_test_method
return attrvalue(self)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 564, in wrapper
return func(self, *args, **kwargs)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 636, in wrapper
func(*args, **kwargs)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/c/typedef/Testtypedef.py",
line 29, in test_with_dwarf
self.image_lookup_for_multiple_typedefs()
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/c/typedef/Testtypedef.py",
line 47, in image_lookup_for_multiple_typedefs
substrs = ['name = "' + t + '"'])
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2833, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : Data type(s) displayed correctly

(Speculation -- perhaps because our clang is /usr/bin/cc?)

-- 
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] Inquiry about .debug_frame

[via lldb-dev]

lldb should be able to read both. Can you file a bug please? 
On Tue, Nov 24, 2015 at 02:50:20PM +0100, Ravitheja Addepally via lldb-dev 
wrote:
> Hello,
>While compiling with clang for i386, I notice that the CFI
> information is distributed between the .eh_frame section and the
> .debug_frame section, meaning for some functions the CFI info is present in
> the .debug_frame section whereas for some it is present in the .eh_frame.
> Now looking at the lldb code,  I see that this information is only read
> from the .eh_frame section and not from the .debug_frame section. My
> questions are the following ->
> 1) Is there something that I missing ? is the  information that I provided
> in this email correct ?
> 2) If it is correct, is this expected behavior ? I mean if the CFI info is
> present in the .debug_frame then I think it should be read ? coz it maybe
> useful in unwinding scenarios ?
> 
> 
> BR,
> A Ravi

> ___
> 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

[lldb-dev] [Bug 25632] New: LLDB does not use the .debug_frame section to read the CFI

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25632

Bug ID: 25632
   Summary: LLDB does not use the .debug_frame section to read the
CFI
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: ravithejaw...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

LLDB does not use the .debug_frame section to read the CFI, this was observed
for clang compiler with 32 bit option on a 64 bit machine. The
DWARFCallFrameInfo class is instantiated with the .eh_frame section, although
sometimes some of the CFI info may also be present in .debug_frame. To
reproduce, compile any C application with clang for 32 bit on a 64 bit machine.

-- 
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 25652] New: [linux] I/O over pty arrives asynchronously, which confuses LLDB

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25652

Bug ID: 25652
   Summary: [linux] I/O over pty arrives asynchronously, which
confuses LLDB
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

According to this  discussion, there is
basically no guarantee about when will I/O from the inferior process arrive.
Specifically, it can arrive after we have it has stopped and we think we have
forwarded all of its input. This can cause two problems:
- the test suite sometimes checks the output of the process to verify it has
done the right thing. The late arrival of this text can cause flakyness.
- gdb-remote protocol does not support forwarding I/O when the process is
stopped. Currently, we will still attempt to do that and then things will
break.

The possible fixes for this would be: patching the kernel (which is a
possibility they seemed opened (or at least not opposed) to), inserting sleeps
or stopping using stdio in tests.

Although it is possible to reliably reproduce it with a specially crafted
program, I have seen this happen on the buildbot only once. Given that this
does not seem to happen very often, it does not seem like a big priority.

However, we should do something about the protocol forwarding issue, because
when this happens, and we are forwarding I/O, the entire debug session will
break down, which is not good.

-- 
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 25653] New: Cannot inspect const static variable

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25653

Bug ID: 25653
   Summary: Cannot inspect const static variable
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: ver...@codeplay.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 15359
  --> https://llvm.org/bugs/attachment.cgi?id=15359&action=edit
simple test case with a const static

Calling "expr" or "target variable" on a constant static global in C doesn't
work. The error is

error: use of undeclared identifier 'limit'

or

error: can't find global variable 'limit'

It seems the variable is given the 'DW_AT_const_value' DWARF attribute. However
lldb can't find it. If you compile slightly differently so is has a
'DW_AT_location' attribute instead, lldb deals with it okay.

This works in gcc, which produces a 'DW_AT_location' attribute.

To reproduce compile with "clang -g -O0 InspectConstStatic.c"
Then call lldb with the commands:

b main
r
expr limit

-- 
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 24717] MiBreakTestCase.test_lldbmi_break_insert_function_pending is marked expectedFlakeyLinux, but still fails

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=24717

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from lab...@google.com ---
Seems to be passing reliably now. I have enabled the test again.

-- 
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 25194] LLDB-Server Assertion raised when single stepping on MIPS

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25194

Sagar  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||sagar.tha...@imgtec.com
 Resolution|--- |FIXED

--- Comment #1 from Sagar  ---
Fixed by commit rL254379.

-- 
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 25703] New: test runner does not feed timeouts through the test event system

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25703

Bug ID: 25703
   Summary: test runner does not feed timeouts through the test
event system
   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

The parallel test runner detects timeouts at the level of running the inferior
dotest.py process and having that take too long to finish.

The code in the parallel test runner that knows about the timeout doesn't have
a connection to the test event system.  It is the dotest inferior (the thing
that timed out and was killed because of it) that had the connection (via
socket) to report test events to the event collector.

When a timeout occurs, a test event should be generated and sent to the event
collector.  This likely will involve making a socket and connecting to the
event collector.

Once this is complete, a basic ResultsFormatter-based test results summary
generation should be able to entirely replace the legacy parallel test summary
output.  (Right now I can replace all of it but the timeout handling).

-- 
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 25703] test runner does not feed timeouts through the test event system

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25703

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

[lldb-dev] [Bug 25742] New: Use After Free Vulnerability lldb_private::Debugger

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25742

Bug ID: 25742
   Summary: Use After Free Vulnerability lldb_private::Debugger
   Product: lldb
   Version: 3.4
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: ichai...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 15398
  --> https://llvm.org/bugs/attachment.cgi?id=15398&action=edit
Proof-of-Concept for the crash

A use after free vulnerability exists in com.apple.LLDB.framework on Apple Mac
OS X 10.11.1 in LLDB version 340.4.110.1, that on exploitation, would allow an
attacker to execute arbitrary code with the privileges of the user. 

Steps to reproduce:

~/D/A/t/lldbPython ❯❯❯ lldb
(lldb)script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> import lldb
>>> s=lldb.SBDebugger.Create()
>>> s.__swig_destroy__(s)
>>> print s


Backtrace of the crash:

0   com.apple.LLDB.framework  0x000105c0ae0a
lldb::SBDebugger::GetDescription(lldb::SBStream&) + 28
1   com.apple.LLDB.framework  0x000105c5be4c
_wrap_SBDebugger___str__(_object*, _object*) + 128
2   org.python.python 0x000108ea0a0b PyEval_EvalFrameEx +
13400
3   org.python.python 0x000108e9d3c1 PyEval_EvalCodeEx +
1583
4   org.python.python 0x000108e422e5 0x108e1a000 + 164581
5   org.python.python 0x000108e24202 PyObject_Call + 99
6   org.python.python 0x000108e2eff5 0x108e1a000 + 86005
7   org.python.python 0x000108e24202 PyObject_Call + 99
8   org.python.python 0x000108ea2e83
PyEval_CallObjectWithKeywords + 165
9   org.python.python 0x000108e6aa8f 0x108e1a000 + 330383
10  org.python.python 0x000108e53e17 _PyObject_Str + 127
11  org.python.python 0x000108e53eb0 PyObject_Str + 12
12  org.python.python 0x000108e53b70 0x108e1a000 + 236400
13  org.python.python 0x000108e3afb3 PyFile_WriteObject +
338
14  org.python.python 0x000108e9fb01 PyEval_EvalFrameEx +
9550
15  org.python.python 0x000108e9d3c1 PyEval_EvalCodeEx +
1583
16  org.python.python 0x000108ea143e PyEval_EvalFrameEx +
16011
17  org.python.python 0x000108e9d3c1 PyEval_EvalCodeEx +
1583
18  org.python.python 0x000108ea34ae 0x108e1a000 + 562350
19  org.python.python 0x000108ea030c PyEval_EvalFrameEx +
11609
20  org.python.python 0x000108e9d3c1 PyEval_EvalCodeEx +
1583
21  org.python.python 0x000108ea34ae 0x108e1a000 + 562350
22  org.python.python 0x000108ea030c PyEval_EvalFrameEx +
11609
23  org.python.python 0x000108ea3541 0x108e1a000 + 562497
24  org.python.python 0x000108ea030c PyEval_EvalFrameEx +
11609
25  org.python.python 0x000108e9d3c1 PyEval_EvalCodeEx +
1583
26  org.python.python 0x000108ea34ae 0x108e1a000 + 562350
27  org.python.python 0x000108ea030c PyEval_EvalFrameEx +
11609
28  org.python.python 0x000108e9d3c1 PyEval_EvalCodeEx +
1583
29  org.python.python 0x000108ea34ae 0x108e1a000 + 562350
30  org.python.python 0x000108ea030c PyEval_EvalFrameEx +
11609
31  org.python.python 0x000108ea3541 0x108e1a000 + 562497
32  org.python.python 0x000108ea030c PyEval_EvalFrameEx +
11609
33  org.python.python 0x000108e9d3c1 PyEval_EvalCodeEx +
1583
34  org.python.python 0x000108e9cd8c PyEval_EvalCode + 54
35  org.python.python 0x000108ebca42 0x108e1a000 + 666178
36  org.python.python 0x000108ebcbff PyRun_StringFlags +
109
37  org.python.python 0x000108ebcb53
PyRun_SimpleStringFlags + 69
38  com.apple.LLDB.framework  0x0001079e1cef
IOHandlerPythonInterpreter::Run() + 245
39  com.apple.LLDB.framework  0x0001078e7b43
lldb_private::Debugger::ExecuteIOHandlers() + 63
40  com.apple.LLDB.framework  0x0001079c89cc
lldb_private::CommandInterpreter::RunCommandInterpreter(bool, bool,
lldb_private::CommandInterpreterRunOptions&) + 126
41  com.apple.LLDB.framework  0x000105c0ca80
lldb::SBDebugger::RunCommandInterpreter(bool, bool) + 68
42  lldb  0x000105bdc05f Driver::MainLoop() +
2347
43  lldb  0x000105bdc594 main + 268
44  libdyld.dylib 0x7fff9654e5ad start + 1

Please find the Proof-of-Concept attached as

[lldb-dev] [Bug 25743] New: TestModulesInlineFunctions.py test_expr() failing on Darwin

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25743

Bug ID: 25743
   Summary: TestModulesInlineFunctions.py test_expr() failing on
Darwin
   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

Looks like we're failing to find the module.

Xcode 7.2 Beta 4, OS X 10.11.1 (15B42), El Capitan.

runCmd: settings set target.clang-module-search-paths
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lang/objc/modules-inline-functions"
output: 

runCmd: expr @import myModule; 3
runCmd failed!
error: Header search couldn't locate module myModule
error: 1 errors parsing expression


FAIL




Traceback (most recent call last):
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 550, in wrapper
return func(self, *args, **kwargs)
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2288, in dsym_test_method
return attrvalue(self)
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lang/objc/modules-inline-functions/TestModulesInlineFunctions.py",
line 51, in test_expr
substrs = ["int", "3"])
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2769, in expect
self.runCmd(str, msg=msg, trace = (True if trace else False), check = not
error, inHistory=inHistory)
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2695, in runCmd
msg if msg else CMD_MSG(cmd))
AssertionError: False is not True : Variable(s) displayed correctly
Config=x86_64-clang
Session info generated @ Fri Dec  4 10:02:44 2015
To rerun this test, issue the following command from the 'test' directory:

./dotest.py -A x86_64 -C clang -v -t  -f
ModulesInlineFunctionsTestCase.test_expr_dsym

-- 
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 25744] New: Linux build breaks when both python 2 and python 3 are installed

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25744

Bug ID: 25744
   Summary: Linux build breaks when both python 2 and python 3 are
installed
   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'm not sure if this is new, but when both Python 2 and 3 are installed on
Linux, the readline overload module has code that is not Python-3 compatible. 
(I'm pretty sure I've run python 2/3 systems in the past and not hit this, so
it might have crept in more recently).

I think we want to limit Linux to Python 2.x in the short term.  Later, we can
iron out the Python 3 bits.  An alternative would be to fix up the basic
wrapper code to work on both Python 2 and 3, but that's a bit more involved.  I
prefer to handle that as a lower priority follow up step.

See initial report here:
https://bugs.swift.org/browse/SR-14

I'm still working on getting the exact repro environment, but calling it out
now.

-- 
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 25785] New: TestReturnValue fails remotely windows->android

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25785

Bug ID: 25785
   Summary: TestReturnValue fails remotely windows->android
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: other
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

I will XFAIL the test until we get a chance to investigate the root cause.

-- 
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 25801] New: Arch Linux fails to build python support

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25801

Bug ID: 25801
   Summary: Arch Linux fails to build python support
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
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

There are possibly two issues here:

* python 2.x and 3.x, where we want to prefer python 2.x
* symbol definitions around Py_InitModule4, where ArchLinux x86_64 is needing
it to be defined Py_InitModule4_64 whereas Ubuntu x86_64 doesn't require that.

Breaking this one out separately from a Gentoo one since the solutions for both
are not necessarily one and the same.

-- 
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 25805] New: TestLoadUnload fails when run from Windows to Android

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25805

Bug ID: 25805
   Summary: TestLoadUnload fails when run from Windows to Android
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: other
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

I am XFAILing the test until we figure it out.

This is what the buildbot says:

==
FAIL: test_lldb_process_load_and_unload_commands_dwarf
(TestLoadUnload.LoadUnloadTestCase)
Test that lldb process load/unload command work correctly.
--
Traceback (most recent call last):
  File
"c:\lldbSlave\lldb-win7-android\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py",
line 566, in wrapper
return func(self, *args, **kwargs)
  File
"c:\lldbSlave\lldb-win7-android\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py",
line 2282, in dwarf_test_method
return attrvalue(self)
  File
"c:\lldbSlave\lldb-win7-android\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py",
line 888, in wrapper
func(*args, **kwargs)
  File
"c:\lldbSlave\lldb-win7-android\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\load_unload\TestLoadUnload.py",
line 220, in test_lldb_process_load_and_unload_commands
'Image [0-9]+ loaded'])
  File
"c:\lldbSlave\lldb-win7-android\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py",
line 2669, in expect
self.runCmd(str, msg=msg, trace = (True if trace else False), check = not
error, inHistory=inHistory)
  File
"c:\lldbSlave\lldb-win7-android\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py",
line 2595, in runCmd
msg if msg else CMD_MSG(cmd))
AssertionError: False is not True : libloadunload_a.so loaded correctly
Config=i386-C:/Toolchains/i386-21/bin/i686-linux-android-gcc.exe

-- 
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 25806] New: Can't set breakpoint in static initializer

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25806

Bug ID: 25806
   Summary: Can't set breakpoint in static initializer
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: tbergham...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

LLDB don't detect the loading of a shared object file linked against the main
executable before the static initializers are executed for the given module.
Because of this it is not possible to get breakpoint hits in these static
initializers and to display proper debug info in case of a crash in these
codes. (The issue isn't happening for dlopen-ed libraries.)

The issue is demonstrated in TestLoadUnlod.py
LoadUnloadTestCase.test_static_init_during_load test case.

My current understanding of the problem:

The problem is that DynamicLoaderPOSIXDYLD first set a breakpoint on the entry
of the main executable based on the content of auxv (it will be libc.so'_start)
and then set the rendezvous breakpoint when the entry breakpoint is hit. The
static initializers are running before libc.so'_start is called so at this
point we haven't loaded the library list and haven't set the rendezvous
breakpoint either.

I think the correct solution to the problem is to change DynamicLoaderPOSIXDYLD
to set the (current) entry breakpoint at a location what is hit before any code
is executed, but I don't know what is the reasonable location for the
(something what works on all platforms).

-- 
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 25819] New: TestNamespaceLookup is failing on linux

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25819

Bug ID: 25819
   Summary: TestNamespaceLookup is failing on linux
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

-- 
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 25825] New: TestWithLimitDebugInfo.py causing error

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25825

Bug ID: 25825
   Summary: TestWithLimitDebugInfo.py causing error
   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'm seeing this on Darwin and Linux:

=
ERROR: test_limit_debug_info_dsym
(TestWithLimitDebugInfo.TestWithLimitDebugInfo)
--
Traceback (most recent call last):
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2247, in test_method
return attrvalue(self)
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1134, in wrapper
if expected_fn(self):
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1096, in fn
debug_info_passes = debug_info is None or self.debug_info in debug_info
TypeError: argument of type 'function' is not iterable
Config=x86_64-clang
==
ERROR: test_limit_debug_info_dwarf
(TestWithLimitDebugInfo.TestWithLimitDebugInfo)
--
Traceback (most recent call last):
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2247, in test_method
return attrvalue(self)
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1134, in wrapper
if expected_fn(self):
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1096, in fn
debug_info_passes = debug_info is None or self.debug_info in debug_info
TypeError: argument of type 'function' is not iterable
Config=x86_64-clang
--

Looks like there is something not right with the decoration?

I skipped this on Darwin and Linux here:
r255549

It likely affects more OSes though.  These are just the two I was watching that
were affected by 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] [Bug 25825] TestWithLimitDebugInfo.py causing error

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25825

Todd Fiala  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Todd Fiala  ---
I think I just missed seeing the fix for it.

I reverted out the test skips as r255542 appears to 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] [Bug 25844] test rerun logic is hanging on android cross compiler buildbot

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25844

Todd Fiala  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   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

[lldb-dev] [Bug 25844] New: test rerun logic is hanging on android cross compiler buildbot

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25844

Bug ID: 25844
   Summary: test rerun logic is hanging on android cross compiler
buildbot
   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

See builds like:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-android/builds/4311

Change coming in a moment to workaround by disabling rerun logic for eligible
tests when aarch64 is in the architecture list.

-- 
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 25847] New: "f s <#>" fails as short form for "frame select <#>"

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25847

Bug ID: 25847
   Summary: "f s <#>" fails as short form for "frame select <#>"
   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

"f s 2" reports "error: invalid arguments." and "error: Frame index
(4294967295) out of range." while "frame select 2" is successful.

Session transcript:

(lldb) target create "/bin/sleep"
Current executable set to '/bin/sleep' (x86_64).
(lldb) settings set -- target.run-args  "3600"
(lldb) run
Process 24755 launching
Process 24755 launched: '/bin/sleep' (x86_64)
Process 24755 stopped
* thread #1: tid = 100103, 0x000800b0925a libc.so.7`__sys_nanosleep + 10 at
_nanosleep.S:3, stop reason = signal SIGSTOP
frame #0: 0x000800b0925a libc.so.7`__sys_nanosleep + 10 at
_nanosleep.S:3
   1#include "compat.h"
   2#include "SYS.h"
-> 3PSEUDO(nanosleep)
   4.section .note.GNU-stack,"",%progbits
(lldb) bt
* thread #1: tid = 100103, 0x000800b0925a libc.so.7`__sys_nanosleep + 10 at
_nanosleep.S:3, stop reason = signal SIGSTOP
  * frame #0: 0x000800b0925a libc.so.7`__sys_nanosleep + 10 at
_nanosleep.S:3
frame #1: 0x00400ae6 sleep`main(argc=,
argv=) + 150 at sleep.c:91 [opt]
frame #2: 0x0040091f sleep`_start(ap=,
cleanup=) + 367 at crt1.c:78 [opt]
(lldb) f s 2
error: invalid arguments.


Command Options Usage:
  frame select [-r ] []

   -r  ( --relative  )
A relative frame index offset from the current frame index.
error: Frame index (4294967295) out of range.
(lldb) frame select 2
sleep was compiled with optimization - stepping may behave oddly; variables may
not be available.
frame #2: 0x0040091f sleep`_start(ap=,
cleanup=) + 367 at crt1.c:78 [opt]
   75   #endif
   76  
   77   handle_static_init(argc, argv, env);
-> 78   exit(main(argc, argv, env));
   79   }
(lldb)

-- 
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 25847] "f s <#>" fails as short form for "frame select <#>"

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25847

Adrian McCarthy  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||amcca...@google.com
   Assignee|lldb-dev@lists.llvm.org |amcca...@google.com

--- Comment #3 from Adrian McCarthy  ---
I'll fix the message.  I was looking at it anyway to make sure this wasn't a
regression caused by my command handling refactor from several months ago.

-- 
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 25653] Cannot inspect const static variable

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25653

Ewan Crawford  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Ewan Crawford  ---
Fixed in revision r255887

-- 
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 25866] New: Gentoo Linux build breaks in some scenarios when both Python 2 and Python 3 are present

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25866

Bug ID: 25866
   Summary: Gentoo Linux build breaks in some scenarios when both
Python 2 and Python 3 are present
   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

This may be the same thing as the issue on Arch Linux; however, one of the
threads on this indicated some tweaking of build environment variables allowed
this to work.

I suspect the fix for handling python 2 and python 3 simultaneously with
preferential treatment for python 2 would handle this.  Filing in case this is
a different issue.

-- 
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 25869] New: OS X lldb crashed during test: ProcessGDBRemote/Broadcaster cleanup segfault

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25869

Bug ID: 25869
   Summary: OS X lldb crashed during test:
ProcessGDBRemote/Broadcaster cleanup segfault
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: MacOS X
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

Created attachment 15480
  --> https://llvm.org/bugs/attachment.cgi?id=15480&action=edit
crashlog

This is on my home iMac, running against lldb r255893.  Crashlog attached.

-- 
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 25872] New: OS X: TestGlobalVariables dwarf is not finding the static const int g_file_static_int

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25872

Bug ID: 25872
   Summary: OS X: TestGlobalVariables dwarf is not finding the
static const int g_file_static_int
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: MacOS X
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

This looks like it started happening very recently:

runCmd: frame variable --show-types --scope --show-globals --no-args
output: STATIC: (const char *) g_func_static_cstr = 0x000103c65f69
"g_func_static_cstr"
STATIC: (const char *) g_file_static_cstr = 0x000103c65f83
"g_file_static_cstr"
STATIC: (const char *) g_func_static_cstr = 0x000103c65f69
"g_func_static_cstr"
GLOBAL: (const char *) g_file_global_cstr = 0x000103c65f56
"g_file_global_cstr"
GLOBAL: (int) g_common_1 = 21
GLOBAL: (int) g_file_global_int = 42


Expecting sub string: GLOBAL: (int) g_file_global_int = 42
Matched

Expecting sub string: STATIC: (const int) g_file_static_int = 2
Not matched

FAIL

 >>: success

Traceback (most recent call last):
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2263, in dwarf_test_method
return attrvalue(self)
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 608, in wrapper
func(*args, **kwargs)
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lang/c/global_variables/TestGlobalVariables.py",
line 60, in test
'GLOBAL: (int) g_common_1 = 21'])
  File
"/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2715, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : Variable(s) displayed correctly
Config=x86_64-clang
Session info generated @ Thu Dec 17 10:46:37 2015
To rerun this test, issue the following command from the 'test' directory:

./dotest.py -A x86_64 -C clang -v -t  -f GlobalVariablesTestCase.test_dwarf


OS X 10.11.2 (15C50)
Xcode 7.2 (7C68)

-- 
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 25872] OS X: TestGlobalVariables dwarf is not finding the static const int g_file_static_int

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25872

Todd Fiala  changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |clayb...@gmail.com

--- Comment #1 from Todd Fiala  ---
We're going to try to fix this.

-- 
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 25896] New: Hide stack frames from specific source files

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25896

Bug ID: 25896
   Summary: Hide stack frames from specific source 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: chinmayga...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

When my program is paused in the debugger, I would like to hide stack frames
originating from certain source files (or libraries) from appearing in the
backtrace. These frames usually correspond to standard library functions that I
am not in the process of actively debugging.

On a similar note, I did find `target.process.thread.step-avoid-regexp` which
allows me to avoid stepping into select frames. However, I want to also
suppress these frames in the backtrace listing, and, avoid showing the same
when move up and down the bracktrace.

-- 
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 25921] New: 3.7 LLDB is broken on i686, while 3.8 (trunk) is just fine

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25921

Bug ID: 25921
   Summary: 3.7 LLDB is broken on i686, while 3.8 (trunk) is just
fine
   Product: lldb
   Version: 3.7
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: costamagnagianfra...@yahoo.it
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

As said in the title llvm 3.7 doesn't build on ubuntu i386 (that defaults to
i686).

the problem is an LLDB test failure.

https://launchpad.net/ubuntu/+source/llvm-toolchain-3.7/1:3.7.1-1ubuntu1/+build/8427360

I came to two conclusions: disable the testsuite for lldb, or disable all lldb
(the latter seems to be the more convenient)
https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.7/+bug/1527865

hovewer seems that 3.8 svn doesn't have this issue, so I guess it is just a
matter of cherry-picking some bits, assuming somebody knows where they are :)

thanks a lot!


Gianfranco

-- 
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 25922] New: lldbinline.py-style tests will not rerun

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25922

Bug ID: 25922
   Summary: lldbinline.py-style tests will not rerun
   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

The test rerun facility cannot run tests implemented through the lldbinline.py
convenience wrapper.

The issue appears to be that the actual TestCase class comes from lldbtest.py,
so the rerun logic (when it asks for the TestCase class path) is attempting to
rerun lldbtest.py.  This is both incorrect vs. intent and is not useful.

I am going to attempt to add an attribute to the test case class created by
lldbsuite.test.lldbinline.MakeInlineTest, and have the test infrastructure
first check for that and use that attribute if present before falling back to
using the path of the class name.  This probably would also fix what I imagine
is a bug in the output of test issues, as other code in output generation looks
at the test case filename.

-- 
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 25922] lldbinline.py-style tests will not rerun

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25922

Todd Fiala  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   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

[lldb-dev] [Bug 25924] New: TestEvents sometimes generating SIGSEGV on OS X

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25924

Bug ID: 25924
   Summary: TestEvents sometimes generating SIGSEGV on OS X
   Product: lldb
   Version: unspecified
  Hardware: Macintosh
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

Now that we're piping exceptional exit information properly through the test
runner, I'm seeing TestEvents.py occasionally exit with a SIGSEGV:

ERROR: [EXCEPTIONAL EXIT 11 (SIGSEGV)] test_listen_for_and_print_event_dsym
(python_api/event/TestEvents.py)

We need to track this down.  I will skip this whole test suite until we can
identify the cause of it.  Right now it is one of the last things that will
intermittently poke through the rerun logic.

-- 
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 25925] New: TestCppNsImport failing on FreeBSD with clang

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25925

Bug ID: 25925
   Summary: TestCppNsImport failing on FreeBSD with clang
   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

This test is marked xfail for gcc >= 4.9; it also fails on FreeBSD with clang.

FAIL: LLDB (/usr/bin/clang-x86_64) :: test_with_run_command_dwarf
(TestCppNsImport.TestCppNsImport)
==
FAIL: test_with_run_command_dwarf (TestCppNsImport.TestCppNsImport)
   Tests imported namespaces in C++.
--
Traceback (most recent call last):
  File
"/tank/emaste/src/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2263, in dwarf_test_method
return attrvalue(self)
  File
"/tank/emaste/src/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 608, in wrapper
func(*args, **kwargs)
  File
"/tank/emaste/src/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/cpp/nsimport/TestCppNsImport.py",
line 55, in test_with_run_command
self.assertTrue(test_result.IsValid() and test_result.GetValueAsSigned() ==
1, "N::n = 1")
AssertionError: False is not True : N::n = 1
Config=x86_64-/usr/bin/clang
--
Ran 1 test in 0.950s

RESULT: FAILED (0 passes, 1 failures, 0 errors, 0 skipped, 0 expected failures,
0 unexpected successes)

[TestCppNsImport.py FAILED]

-- 
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 26010] New: LLDB fails to display content of a variable size array

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26010

Bug ID: 26010
   Summary: LLDB fails to display content of a variable size array
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: tbergham...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Compile the following code snippet with g++ (tested with 4.8.2 on Linux
x86_64):

int main() {
for (int i = 0; i < 10; ++i) {
int x[i + 1];
x[0] = sizeof(x);
x[0] *= 2; // Break here
}
}

Break at the marked line and display the variable x with executing the "frame
variable x" command.

Expected behavior is to display x as an array with the number of displayed
elements matching with the actual element count of the array in the current
implementation.

Actual behavior is that the array is always displayed with 4 element regardless
of the current iteration.

In the same scenario gdb displays the array with the correct number of element.

If the inferior is compiled with clang then gdb fails as well because incorrect
debug info is generated (http://llvm.org/pr25934)

The problem is that for variable sized arrays g++ correctly generates a
DW_TAG_subrange_type children with a DW_AT_upper_bound attribute containing a
dwarf expression pointing to the location where the current size of the array
is stored but LLDB don't handle the case where DW_AT_upper_bound is a dwarf
expression.

-- 
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 26028] New: TestMiGdbSetShow.test_lldbmi_gdb_set_target_async_on is flaky on linux

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26028

Bug ID: 26028
   Summary: TestMiGdbSetShow.test_lldbmi_gdb_set_target_async_on
is flaky on linux
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Fails about 1% of the time. See builds 9866, 9933 and 9967 on the ubuntu
builder .

Error message:
==
ERROR: test_lldbmi_gdb_set_target_async_on
(TestMiGdbSetShow.MiGdbSetShowTestCase)
   Test that 'lldb-mi --interpreter' can execute commands in async mode.
--
Traceback (most recent call last):
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 608, in wrapper
func(*args, **kwargs)
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/tools/lldb-mi/TestMiGdbSetShow.py",
line 62, in test_lldbmi_gdb_set_target_async_on
self.expect("@\"argc=1")
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/tools/lldb-mi/lldbmi_testcase.py",
line 54, in expect
return self.child.expect(pattern, *args, **kwargs)
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
line 1316, in expect
return self.expect_list(compiled_pattern_list, timeout, searchwindowsize)
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
line 1330, in expect_list
return self.expect_loop(searcher_re(pattern_list), timeout,
searchwindowsize)
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
line 1414, in expect_loop
raise TIMEOUT (str(e) + '\n' + str(self))
TIMEOUT: Timeout exceeded in read_nonblocking().

version: 2.4 ($Revision: 516 $)
command: /lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/lldb-mi
args: ['/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/lldb-mi',
'--interpreter']
searcher: searcher_re:
0: re.compile("@"argc=1")
buffer (last 100 chars): roup-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
(gdb)

before (last 100 chars): roup-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
(gdb)

after: 
match: None
match_index: None
exitstatus: None
flag_eof: False
pid: 2838
child_fd: 7
closed: False
timeout: 30
delimiter: 
logfile: None
logfile_read: 
logfile_send: None
maxread: 2000
ignorecase: False
searchwindowsize: None
delaybeforesend: 0.05
delayafterclose: 0.1
delayafterterminate: 0.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 25092] Test suit is flaky if 2 tests have the same file name

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25092

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||lab...@google.com
 Resolution|--- |FIXED

--- Comment #4 from lab...@google.com ---
As of r249837, it should not be possible to have two tests with the same name,
so I am going to close this. Feel free to reopen if you think more needs to be
done about this.

-- 
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 26031] New: Ptrace interface unable to set byte select watchpoints on arm-linux

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26031

Bug ID: 26031
   Summary: Ptrace interface unable to set byte select watchpoints
on arm-linux
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: omair.jav...@linaro.org
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Following tests fail on arm-linux:

TestWatchLocationWithWatchSet.py
TestStepOverWatchpoint.py

Ptrace interface fails to set read/write watchpoints on single byte variables
which are not word aligned.

Following commands fail, in case of TestStepOverWatchpoint:

watchpoint set variable -w read g_watch_me_write

Following commands fail, in case of TestWatchLocationWithWatchSet:

watchpoint set expression -w write -s 1 -- g_char_ptr + 7


Need to do further investigation on how to make sure we can select individual
bytes while setting watchpoints on arm.

-- 
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 26102] New: msbuild: MSB5004: The solution file has two projects named 'lldb tests'

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26102

Bug ID: 26102
   Summary: msbuild: MSB5004: The solution file has two projects
named 'lldb tests'
   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: red.skot...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

while compile lldb as part of llvm i have error MSB5004: The solution file has
two projects named 'lldb tests' in LLVM.sln

-- 
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 25921] 3.7 LLDB is broken on i686, while 3.8 (trunk) is just fine

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25921

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from lab...@google.com ---
I'm gonna close the issue then. It would still be good if you could check out
3.8 early to make sure it works for you.

-- 
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 26139] New: CommandScriptImmediateOutputTestCase fails on Linux

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26139

Bug ID: 26139
   Summary: CommandScriptImmediateOutputTestCase fails on Linux
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: tbergham...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

The test fails on Linux with all tested architecture and compiler with the
following error:

==
ERROR: test_command_script_immediate_output_dwarf
(TestCommandScriptImmediateOutput.CommandScriptImmediateOutputTestCase)
   Test that LLDB correctly allows scripted commands to set an immediate output
file.
--
Traceback (most recent call last):
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2249, in dwarf_test_method
return attrvalue(self)
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 836, in wrapper
func(*args, **kwargs)
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 769, in wrapper
func(*args, **kwargs)
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 769, in wrapper
func(*args, **kwargs)
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 608, in wrapper
func(*args, **kwargs)
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py",
line 35, in test_command_script_immediate_output
self.sendline('mycommand', patterns='this is a test string, just a test
string')
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbpexpect.py",
line 57, in sendline
return self.sendimpl(self.child.sendline, command, patterns, timeout,
exact)
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbpexpect.py",
line 51, in sendimpl
return self.expect(patterns=patterns, timeout=timeout, exact=exact)
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbpexpect.py",
line 40, in expect
return self.child.expect(patterns, timeout=timeout)
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
line 1316, in expect
return self.expect_list(compiled_pattern_list, timeout, searchwindowsize)
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
line 1330, in expect_list
return self.expect_loop(searcher_re(pattern_list), timeout,
searchwindowsize)
  File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
line 1414, in expect_loop
raise TIMEOUT (str(e) + '\n' + str(self))

-- 
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 26165] New: Support moving between words in prompt with ctrl+left/right

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26165

Bug ID: 26165
   Summary: Support moving between words in prompt with
ctrl+left/right
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: o...@avtalion.name
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

As mentioned in the following mailing list thread, LLDB should have built-in
support for hotkeys for moving between words, specifically ctrl+left/right.

http://lists.llvm.org/pipermail/lldb-dev/2016-January/009271.html

This is a very common use-case, particularly useful when editing long lines of
text (such as when typing commands in the Swift REPL, based on LLDB). At the
moment, LLDB spits out ;5C and ;5D which causes even more problems, forcing you
to delete those errant characters.

These are the two bindings I'm suggesting, taken from my ~/.editrc:
 bind "\e[1;5C" em-next-word
 bind "\e[1;5D" ed-prev-word

These specific commands match how both Bash and Emacs handle ctrl+left/right.
Ctrl+right moves the cursor forward, stopping directly after the last letter of
the current word.
Ctrl+left moves the cursor back to the first letter of the closest word.

Vi's behavior is a bit different, always moving forward/back to the start of a
word. For "vi-mode", these seem to fit:
  bind "\e[1;5C" vi-next-word
  bind "\e[1;5D" vi-prev-word

(ed-prev-word and vi-prev-word call different functions in libedit, with
slightly different code, but behavior seems to be identical.)

-- 
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 26188] New: FileSpec::RemoveBackupDots should also remove single dots

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26188

Bug ID: 26188
   Summary: FileSpec::RemoveBackupDots should also remove single
dots
   Product: lldb
   Version: 3.8
  Hardware: PC
OS: Windows XP
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: vadi...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

A breakpoint being set in file C:\foo\bar.c won't match a compile unit with
DW_AT_comp_dir=C:\foo and DW_AT_name=.\bar.c 

I've discovered this by debugging LLDB while trying to figure out why wouldn't
it set a breakpoint by full file path+line.  It seems that the compile unit
path gets transformed into a FileSpec { m_directory="c:\foo\.",
m_filename="bar.c" ... }, and that trailing dot prevents a match.  One way to
fix this would be to teach FileSpec::RemoveBackupDots to strip single dots from
paths, since they don't add anything semantically.

-- 
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 26206] New: TestExitDuringStep sometimes hangs on android

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26206

Bug ID: 26206
   Summary: TestExitDuringStep sometimes hangs on android
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Test sometimes hangs on the linux->android buildbot. The logs seem to indicate
that the process is simply not hitting the breakpoint after the initial "run"
command. It's hard to diagnose further without getting logs from the server
(which we are not collecting at the moment).

-- 
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 26230] New: LLDB generates superfluous "running" public events

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26230

Bug ID: 26230
   Summary: LLDB generates superfluous "running" public events
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

LLDB generates the following sequence of public events when stepping over a
conditional breakpoint (when the condition is false):

Got event: stopped , restarted:  True
Got event: running

the second event is unneeded as the first one has already had the "restarted"
bit set, and the process state has remained "running". We should make sure the
second event is not broadcast.

See  for
context.

-- 
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 24953] Unusable with LLVM_LINK_LLVM_DYLIB=ON

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=24953

lab...@google.com changed:

   What|Removed |Added

 CC||lab...@google.com
   Assignee|lldb-dev@lists.llvm.org |lab...@google.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

[lldb-dev] [Bug 26248] New: Disassembly incorrect for x64 RIP-relative

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26248

Bug ID: 26248
   Summary: Disassembly incorrect for x64 RIP-relative
   Product: lldb
   Version: 3.4
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: m...@microsoft.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 15687
  --> https://llvm.org/bugs/attachment.cgi?id=15687&action=edit
Program demonstrates incorrect disassembly for x64 RIP relative.

The disassemble command for x64 RIP relative addressing modes displays the
wrong disassembly. As an example, the byte sequence

  49 8b 05 78 56 34 12

disassembles to three instructions like

(lldb) di -c3 -b -s &a
  0x7fff5fbff740: 49 8b 05  movq   (%r13), %rax
  0x7fff5fbff743: 78 56 js 0x7fff5fbff79b
  0x7fff5fbff745: 34 12 xorb   $0x12, %al

when it should produce a single instruction like

  0x7fff5fbff740: 49 8b 05 78 56 34 12  movq   (%rip + 12345679), %rax

I've attached a small C++ program to demonstrate the problem in the debugger.
The program just declares an array to hold the byte sequence above and then
prints out instructions to copy/paste into the LLDB. Here are the instructions
from the attached program (note that g++ on the Mac maps to LLVM).

REPRO STEPS:

g++ -g lldb-disassemble-rip.cxx
lldb a.out
breakpoint set -f lldb-disassemble-rip.cxx -l 7
r
di -c3 -b -s &a

EXPECT:
  Something like
  (lldb) di -c3 -b -s &a
0x7fff5fbff740: 49 8b 05 78 56 34 12  movq   (%rip + 12345679), %rax

OBSERVE:
  Something like
  (lldb) di -c3 -b -s &a
0x7fff5fbff740: 49 8b 05  movq   (%r13), %rax
0x7fff5fbff743: 78 56 js 0x7fff5fbff79b
0x7fff5fbff745: 34 12 xorb   $0x12, %al

I am seeing this problem on Mac OS X Yosemite Version 10.10.5 with
lldb-340.4.110.1.

This bug may be more impactful than incorrect output if it prevents lldb from
single stepping. In order to test whether lldb single stepping is broken, one
would need an example with the correct stack unwinding provisions.

-- 
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 26261] New: gtest failure in PythonDataObjectsTest.TestPythonBytes on OS X 10.11

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26261

Bug ID: 26261
   Summary: gtest failure in PythonDataObjectsTest.TestPythonBytes
on OS X 10.11
   Product: lldb
   Version: unspecified
  Hardware: Macintosh
OS: MacOS X
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

[ RUN  ] PythonDataObjectsTest.TestPythonBytes
/Users/tfiala/lldb/tot/git-svn/lldb/unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp:212:
Failure
Value of: python_bytes.GetObjectType()
  Actual: 4-byte object <05-00 00-00>
Expected: PyObjectType::Bytes
Which is: 4-byte object <06-00 00-00>

This test is causing the gtest run to fail.

I'll need to disable it on OS X as soon as I get the OS X Green Dragon buildbot
to run (instead of just build) the lldb-gtest target.  (I just discovered it
was only building and not running it while investigating this).

-- 
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 26265] New: [Windows] Evaluating arguments gives incorrect values except for frame 0

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26265

Bug ID: 26265
   Summary: [Windows] Evaluating arguments gives incorrect values
except for frame 0
   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: amcca...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

TextConditionalBreak.py fails on Windows when trying to evaluate a function
argument in frame 1.

Manual experiments indicates this is problem for arguments in any frame other
than frame 0.  This is observable in expression and backtraces.

(lldb) thread backtrace
* thread #1: tid = 0x1144, 0x0112b08a a.out`c(val=3) + 10 at main.c:39, stop
reason = breakpoint 2.1
  * frame #0: 0x0112b08a a.out`c(val=3) + 10 at main.c:39
frame #1: 0x0112b03e a.out`a(val=4586500) + 62 at main.c:27
frame #2: 0x0112b12b a.out`main(argc=0, argv=0x0045fc04) + 139 at main.c:50
frame #3: 0x0112b88f a.out`$LN27 + 224

Note that the correct value for val in frame #0 is correct (3), but incorrect
in frame #1.

(lldb) thread step-out
(lldb) Process 9808 stopped
* thread #1: tid = 0x1144, 0x0112b03e a.out`a(val=3) + 62 at main.c:27, stop
reason = step out
frame #0: 0x0112b03e a.out`a(val=3) + 62 at main.c:27
   24   if (val <= 1)
   25   return b(val);
   26   else if (val >= 3)
-> 27   return c(val); // Find the line number where c's parent frame
is a here.
   28
   29   return val;
   30   }
thread back
* thread #1: tid = 0x1144, 0x0112b03e a.out`a(val=3) + 62 at main.c:27, stop
reason = step out
  * frame #0: 0x0112b03e a.out`a(val=3) + 62 at main.c:27
frame #1: 0x0112b12b a.out`main(argc=3, argv=0x0003) + 139 at main.c:50
frame #2: 0x0112b88f a.out`$LN27 + 224

After stepping back out to what was frame #1, and val is now correctly shown.

-- 
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 26267] New: IncompleteModulesTestCase asserting in clang on Darwin with Xcode 7.3 Beta 1

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26267

Bug ID: 26267
   Summary: IncompleteModulesTestCase asserting in clang on Darwin
with Xcode 7.3 Beta 1
   Product: lldb
   Version: unspecified
  Hardware: Macintosh
OS: MacOS X
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

Exiting test on signal on the testbot, due to clang hitting an exception
somewhere in expression evaluation of the module import:

Session logs for test failures/errors/unexpected successes will go into
directory '2016-01-22-17_48_50'
Command invoked:
/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/test/dotest.py --apple-sdk
macosx
--executable=/Users/buildslave/jenkins/sharedspace/lldb@2/lldb-build/Build/Products/Debug/lldb
--rerun-all-issues --env TERM=vt100 -s 2016-01-22-17_48_50 --results-port 54304
--inferior -p TestIncompleteModules.py
/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test
--event-add-entries worker_index=0:int

Configuration: arch=x86_64
compiler=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
--
Collected 2 tests

Assertion failed: (DeclKind != Decl::LinkageSpec && "Should not perform lookups
into linkage specs!"), function lookup, file
/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/llvm/tools/clang/lib/AST/DeclBase.cpp,
line 1370.

[TestIncompleteModules.py FAILED]
Command invoked: /usr/bin/python
/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/test/dotest.py --apple-sdk
macosx
--executable=/Users/buildslave/jenkins/sharedspace/lldb@2/lldb-build/Build/Products/Debug/lldb
--rerun-all-issues --env TERM=vt100 -s 2016-01-22-17_48_50 --results-port 54304
--inferior -p TestIncompleteModules.py
/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test
--event-add-entries worker_index=0:int

289 out of 422 test suites processed - TestIncompleteModules.py


Sean Callanan is aware of this.  I'm just adding this bug to track in the test
I skip.

-- 
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 26289] New: lldb host crashes with allocation failure when attaching to a remote android target

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26289

Bug ID: 26289
   Summary: lldb host crashes with allocation failure when
attaching to a remote android target
   Product: lldb
   Version: unspecified
  Hardware: Other
OS: other
Status: NEW
  Severity: release blocker
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: luke.drumm...@codeplay.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 15704
  --> https://llvm.org/bugs/attachment.cgi?id=15704&action=edit
attempting to attach to a remote android process with all logging enabled

lldb as of r258122 is crashing during process attach to a remote Android x86_64
target due to a `std::bad_alloc` being raised during the process of loading
symbols.

## Short log (log enable lldb all is attached)
```
(lldb) log enable lldb process
(lldb) log enable lldb language
(lldb) log enable lldb expression
(lldb) platform select remote-android
  Platform: remote-android
 Connected: no
(lldb) platform connect connect://localhost:1234
  Platform: remote-android
Triple: x86_64-*-linux
OS Version: 23.0.0 (3.10.0+)
Kernel: #24 PREEMPT Fri Oct 30 16:57:39 PDT 2015
  Hostname: localhost
 Connected: yes
WorkingDir: /
(lldb) process attach -p 2744
Process::SetPrivateState (connected)
Process::ControlPrivateStateThread (signal = 4)
Sending control event of type: 4.
Process::RunPrivateStateThread (arg = 0xb12b30, pid = 0) thread starting...
Process::WaitForEventsPrivate (timeout = (nil), event_sp)...
Process::RunPrivateStateThread (arg = 0xb12b30, pid = 0) got a control event: 4
Process::WaitForEventsPrivate (timeout = (nil), event_sp)...
Process::ShouldBroadcastEvent (0xb34290) => new state: connected, last
broadcast state: connected - YES
Process::HandlePrivateEvent (pid = 0) broadcasting new state connected (old
state unloaded) to hijacked
Process::SetPublicState (state = attaching, restarted = 0)
Process::WaitForEventsPrivate (timeout = (nil), event_sp)...
Process::AttachCompletionHandler::AttachCompletionHandler process=0xb12b30,
exec_count=0
Process::WaitForProcessToStop (timeout = (nil))
Process::WaitForStateChangedEvents (timeout = (nil), event_sp)...
Process::SetPublicState (state = connected, restarted = 0)
Process::WaitForStateChangedEvents (timeout = (nil), event_sp) => connected
Process::WaitForStateChangedEvents (timeout = (nil), event_sp)...
Process::SetPrivateState (stopped)
Process::SetPrivateState (stopped) stop_id = 1
Process::AttachCompletionHandler::PerformAction called with state stopped (5)
Process::AttachCompletionHandler::PerformAction state stopped: no more execs
expected to start, continuing with attach
Process::CompleteAttach()
Process::CompleteAttach replacing process architecture with DidAttach()
architecture: x86_64--linux-android
ProcessGDBRemote::GetLoadedModuleList
ProcessGDBRemote::GetLoadedModuleList
ProcessGDBRemote::GetLoadedModuleList
ProcessGDBRemote::GetLoadedModuleList
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted
```

## Backtrace

```
* thread #4: tid = 9129, 0x7f51a4374cc9 libc.so.6`gsignal + 57, name =
'intern-state', stop reason = signal SIGABRT
  * frame #0: 0x7f51a4374cc9 libc.so.6`gsignal + 57
frame #1: 0x7f51a43780d8 libc.so.6`abort + 328
frame #2: 0x7f51a4763535
libstdc++.so.6`__gnu_cxx::__verbose_terminate_handler() + 341
frame #3: 0x7f51a47616d6 libstdc++.so.6`??? + 6
frame #4: 0x7f51a4761703 libstdc++.so.6`std::terminate() + 19
frame #5: 0x7f51a4761922 libstdc++.so.6`__cxa_throw + 114
frame #6: 0x7f51a4761e0d libstdc++.so.6`operator new(unsigned long) +
125
frame #7: 0x7f51a5683a82
liblldb.so.3.9.0`__gnu_cxx::new_allocator::allocate(this=0x7f519efc1e40, __n=4720169055844,
(null)=0x) + 60 at new_allocator.h:104
frame #8: 0x7f51a56836d7 liblldb.so.3.9.0`std::_Vector_base >::_M_allocate(this=0x7f519efc1e40,
__n=4720169055844) + 47 at stl_vector.h:168
frame #9: 0x7f51a592bb91 liblldb.so.3.9.0`std::_Vector_base
>::_M_create_storage(this=0x7f519efc1e40, __n=4720169055844) + 35 at
stl_vector.h:181
frame #10: 0x7f51a59294ae liblldb.so.3.9.0`std::_Vector_base >::_Vector_base(this=0x7f519efc1e40,
__n=4720169055844, __a=0x7f5194046908) + 58 at stl_vector.h:136
frame #11: 0x7f51a668725f liblldb.so.3.9.0`std::vector >::vector(this=0x7f519efc1e40,
__n=4720169055844, __value=0x7f519efc1ebc, __a=0x7f5194046908) + 47 at
stl_vector.h:283
frame #12: 0x7f51a6696d59 liblldb.so.3.9.0`std::vector >::_M_fill_assign(this=0x7f5194046908,
__n=4720169055844, __val=0x7f519efc1ebc) + 79 at vector.tcc:223
frame #13: 0x7f51a6696b8b liblldb.so.3.9.0`std::vector >::assign(this=0x7f5194046908,
__n=4720169055844, __val=0x7f519

[lldb-dev] [Bug 26322] New: Core load hangs

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26322

Bug ID: 26322
   Summary: Core load hangs
   Product: lldb
   Version: 3.8
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: eugen...@hotmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

There are two problems with core load on Linux:

1. The thread ID are lost and there is FIXME in the code
2. If core dump is obtained from live process (i.e. gdb attach, gcore, detach)
then there is no thread that has any reason to stop. LLDB hangs forever on such
a core.

Here is the proposed fix for both:

diff --git a/include/lldb/Target/Process.h b/include/lldb/Target/Process.h
index 6bb7a3d..915ca15 100644
--- a/include/lldb/Target/Process.h
+++ b/include/lldb/Target/Process.h
@@ -3401,6 +3401,7 @@ protected:
 std::map m_resolved_indirect_addresses;
 bool m_destroy_in_process;
 bool m_can_interpret_function_calls; // Some targets, e.g the OSX kernel,
don't support the ability to modify the stack.
+bool m_load_core; // True if we are looking at a core dump, not at a
running program
 WarningsCollection  m_warnings_issued;  // A set of object
pointers which have already had warnings printed

 enum {
diff --git a/source/Plugins/Process/elf-core/ProcessElfCore.cpp
b/source/Plugins/Process/elf-core/ProcessElfCore.cpp
index 5b5d98a..fa057f1 100644
--- a/source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ b/source/Plugins/Process/elf-core/ProcessElfCore.cpp
@@ -559,11 +559,10 @@ ProcessElfCore::ParseThreadContextsFromNoteSegment(const
elf::ELFProgramHeader *
 have_prstatus = true;
 prstatus.Parse(note_data, arch);
 thread_data->signo = prstatus.pr_cursig;
+thread_data->tid = prstatus.pr_pid;
 header_size = ELFLinuxPrStatus::GetSize(arch);
 len = note_data.GetByteSize() - header_size;
 thread_data->gpregset = DataExtractor(note_data,
header_size, len);
-// FIXME: Obtain actual tid on Linux
-thread_data->tid = m_thread_data.size();
 break;
 case NT_FPREGSET:
 thread_data->fpregset = note_data;
diff --git a/source/Target/Process.cpp b/source/Target/Process.cpp
index e4fe419..489b307 100644
--- a/source/Target/Process.cpp
+++ b/source/Target/Process.cpp
@@ -767,6 +767,7 @@ Process::Process(lldb::TargetSP target_sp, Listener
&listener, const UnixSignals
 m_last_broadcast_state (eStateInvalid),
 m_destroy_in_process (false),
 m_can_interpret_function_calls(false),
+m_load_core(false),
 m_warnings_issued (),
 m_can_jit(eCanJITDontKnow)
{
@@ -3088,6 +3089,7 @@ Process::LoadCore ()
 // We successfully loaded a core file, now pretend we stopped so we
can
 // show all of the threads in the core file and explore the crashed
 // state.
+m_load_core = true;
 SetPrivateState (eStateStopped);

 // Wait indefinitely for a stopped event since we just posted one
above...
@@ -3975,6 +3977,11 @@ Process::ShouldBroadcastEvent (Event *event_ptr)

 if (!was_restarted)
 should_resume = m_thread_list.ShouldStop (event_ptr) ==
false;
+
+ // ShouldStop() above has some side effects besides
calculating return value,
+ // so we better not skip it. But if we are loading core we
should not resume.
+ if (m_load_core)
+ should_resume = false;

 if (was_restarted || should_resume || m_resume_requested)
 {

-- 
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 19311] LLDB does not stop at breakpoint on resumed-to instruction (on FreeBSD) -- ThreadPlanStepOverBreakpoint skips subsequent braeakpoint

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=19311

abhiinnit...@gmail.com changed:

   What|Removed |Added

 CC||abhiinnit...@gmail.com
   Assignee|lldb-dev@lists.llvm.org |abhiinnit...@gmail.com

--- Comment #2 from abhiinnit...@gmail.com ---
I am working on resolving this issue. I will upstream the fix soon.

-- 
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 23039] DynamicValueChildCountTestCase.test_get_dynamic_vals_with_dwarf failure

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=23039

abhiinnit...@gmail.com changed:

   What|Removed |Added

 CC||abhiinnit...@gmail.com
   Assignee|lldb-dev@lists.llvm.org |abhiinnit...@gmail.com

--- Comment #2 from abhiinnit...@gmail.com ---
I am working on resolving this issue. I will upstream the fix soon.

-- 
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 26335] New: lldb (after 3.7.x) compilation fails at link-time with shared library

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26335

Bug ID: 26335
   Summary: lldb (after 3.7.x) compilation fails at link-time with
shared library
   Product: lldb
   Version: 3.8
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: voyageu...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 15726
  --> https://llvm.org/bugs/attachment.cgi?id=15726&action=edit
Build log showing lldb link failure

Link operation fails in lllb for versions > 3.7 (3.7.1 works fine), with shared
library and --as-needed link flag (enabled by default in most distributions).
There are many errors "undefined reference to `llvm::*". I am attaching a full
build log (bzipped for size).
It would be nice to have this one fixed for 3.8 release

Note: this is on trunk build, but I saw it too before the 3.8 branch (the
Gentoo ebuild for 3.8 rc1 is not ready yet)

FAILED: : && /usr/bin/x86_64-pc-linux-gnu-g++   -march=native -O2 -pipe  -fPIC
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long
-Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment
-Werror=date-time -std=c++11 -ffunction-sections -fdata-sections
-Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing
-Wno-deprecated-register -Wno-vla-extension  -fno-exceptions -fno-rtti  -Wl,-O1
-Wl,--as-needed -Wl,-allow-shlib-undefined -Wl,-O3 -Wl,--gc-sections
tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/Acceptor.cpp.o
tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/lldb-gdbserver.cpp.o
tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/lldb-platform.cpp.o
tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/lldb-server.cpp.o
tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/LLDBServerUtilities.cpp.o
 -o bin/lldb-server-3.9.0  lib64/liblldb.so.3.9.0 -lcurses -lform -lpanel
-lcurses -lpython2.7 -lxml2 -lpthread -ldl -lcurses -lform -lpanel
lib64/libLLVMBPFCodeGen.so lib64/libLLVMBPFAsmPrinter.so
lib64/libLLVMBPFDesc.so lib64/libLLVMBPFInfo.so
lib64/libLLVMCppBackendCodeGen.so lib64/libLLVMCppBackendInfo.so
lib64/libLLVMX86CodeGen.so lib64/libLLVMX86AsmPrinter.so
lib64/libLLVMX86AsmParser.so lib64/libLLVMX86Desc.so lib64/libLLVMX86Info.so
lib64/libLLVMX86Disassembler.so lib64/libLLVMInterpreter.so
lib64/libLLVMAsmParser.so lib64/libLLVMBitReader.so lib64/libLLVMBitWriter.so
lib64/libLLVMCodeGen.so lib64/libLLVMipo.so lib64/libLLVMSelectionDAG.so
lib64/libLLVMMC.so lib64/libLLVMMCJIT.so lib64/libLLVMCore.so
lib64/libLLVMMCDisassembler.so lib64/libLLVMExecutionEngine.so
lib64/libLLVMRuntimeDyld.so lib64/libLLVMOption.so lib64/libLLVMSupport.so
-Wl,--start-group lib64/liblldbBase.a lib64/liblldbBreakpoint.a
lib64/liblldbCommands.a lib64/liblldbDataFormatters.a lib64/liblldbHost.a
lib64/liblldbCore.a lib64/liblldbExpression.a lib64/liblldbInitialization.a
lib64/liblldbInterpreter.a lib64/liblldbSymbol.a lib64/liblldbTarget.a
lib64/liblldbUtility.a lib64/liblldbPluginDisassemblerLLVM.a
lib64/liblldbPluginSymbolFileDWARF.a lib64/liblldbPluginSymbolFileSymtab.a
lib64/liblldbPluginDynamicLoaderStatic.a
lib64/liblldbPluginDynamicLoaderPosixDYLD.a
lib64/liblldbPluginDynamicLoaderHexagonDYLD.a
lib64/liblldbPluginDynamicLoaderWindowsDYLD.a
lib64/liblldbPluginCPlusPlusLanguage.a lib64/liblldbPluginGoLanguage.a
lib64/liblldbPluginObjCLanguage.a lib64/liblldbPluginObjCPlusPlusLanguage.a
lib64/liblldbPluginObjectFileELF.a lib64/liblldbPluginObjectFileJIT.a
lib64/liblldbPluginSymbolVendorELF.a
lib64/liblldbPluginObjectContainerBSDArchive.a
lib64/liblldbPluginObjectContainerMachOArchive.a
lib64/liblldbPluginProcessGDBRemote.a lib64/liblldbPluginProcessUtility.a
lib64/liblldbPluginPlatformAndroid.a lib64/liblldbPluginPlatformGDB.a
lib64/liblldbPluginPlatformFreeBSD.a lib64/liblldbPluginPlatformKalimba.a
lib64/liblldbPluginPlatformLinux.a lib64/liblldbPluginPlatformNetBSD.a
lib64/liblldbPluginPlatformPOSIX.a lib64/liblldbPluginPlatformWindows.a
lib64/liblldbPluginPlatformMacOSX.a
lib64/liblldbPluginDynamicLoaderMacOSXDYLD.a
lib64/liblldbPluginUnwindAssemblyInstEmulation.a
lib64/liblldbPluginUnwindAssemblyX86.a lib64/liblldbPluginAppleObjCRuntime.a
lib64/liblldbPluginRenderScriptRuntime.a lib64/liblldbPluginLanguageRuntimeGo.a
lib64/liblldbPluginCXXItaniumABI.a lib64/liblldbPluginABIMacOSX_arm.a
lib64/liblldbPluginABIMacOSX_arm64.a lib64/liblldbPluginABIMacOSX_i386.a
lib64/liblldbPluginABISysV_arm.a lib64/liblldbPluginABISysV_arm64.a
lib64/liblldbPluginABISysV_i386.a lib64/liblldbPluginABISysV_x86_64.a
lib64/liblldbPluginABISysV_hexagon.a lib64/liblldbPluginABISysV_ppc.a
lib64/liblldbPluginABISysV_ppc64.a lib64/liblldbPluginABISysV_mips.a
lib64/liblldbPluginABISysV_mips64.a lib64/liblldbPluginIn

[lldb-dev] [Bug 26335] lldb (after 3.7.x) compilation fails at link-time with shared library

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26335

lab...@google.com changed:

   What|Removed |Added

 CC||lab...@google.com
   Assignee|lldb-dev@lists.llvm.org |lab...@google.com

--- Comment #1 from lab...@google.com ---
It's a bit shot in the dark, but could you try if

solves your problem?

-- 
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 26339] New: TestCPPAuto.py fails on Windows

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26339

Bug ID: 26339
   Summary: TestCPPAuto.py fails on Windows
   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: amcca...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

On Windows, expression commands like this:

  (lldb) expr struct Test { int x; int y; Test() : x(123), y(456) {} }; auto t
= Test(); t

result in:

  error: Can't run the expression locally: (null)

This requires more research to understand the root problem.

-- 
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 26363] New: lldb 3.8.0.rc1 fails to build out of llvm tree

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26363

Bug ID: 26363
   Summary: lldb 3.8.0.rc1 fails to build out of llvm tree
   Product: lldb
   Version: 3.8
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: su...@fb.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Build and install llvm, clang and compiler-rt. Clone lldb into a directory
outside of llvm tree. Build it:
```
% cmake -G Ninja -DCMAKE_BUILD_TYPE=Release
-DLLDB_PATH_TO_LLVM_BUILD=/home/sugak/llvm/3.8.0/centos6-native/da39a3e
-DLLDB_PATH_TO_CLANG_BUILD=/home/sugak/llvm/3.8.0/centos6-native/da39a3e
% ninja

FAILED: /home/sugak/gcc/4.9.x/centos6-native/1317bc4/bin/g++  
-DHAVE_NR_PROCESS_VM_READV -DHAVE_ROUND -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O3 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
-fno-omit-frame-pointer -momit-leaf-frame-pointer -m64 -mtune=generic
-isystem/home/sugak/python/2.7.8/centos6-native/da39a3e/include
-isystem/home/sugak/ncurses/5.9/centos6-native/da39a3e/include
-isystem/home/engshare/third-party2/libedit/3.1/centos6-native/e1c8e90/include
-isystem/home/engshare/third-party2/llvm-fb/stable/centos6-native/da39a3e/include
 -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -ffu
nction-sections -fdata-sections -Wno-deprecated-declarations
-Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register
-Wno-vla-extension  -fno-exceptions -fno-rtti -O3 -DNDEBUG -Itools/lldb-mi
-I/home/sugak/lldb/3.8.0.rc1/src/lldb/tools/lldb-mi
-I/home/sugak/lldb/3.8.0.rc1/src/lldb/include -Iinclude
-I/home/sugak/llvm/3.8.0/centos6-native/da39a3e/include
-I/home/lldb/3.8.0.rc1/src/lldb/source
-I/home/sugak/python/2.7.8/centos6-native/da39a3e/include/python2.7
-I/home/sugak/lldb/3.8.0.rc1/src/lldb/tools/clang/include -I../clang/include
-I/home/sugak/ncurses/5.9/centos6-native/da39a3e/includ
e -MMD -MT tools/lldb-mi/CMakeFiles/lldb-mi.dir/MICmdCmdData.cpp.o -MF
tools/lldb-mi/CMakeFiles/lldb-mi.dir/MICmdCmdData.cpp.o.d -o
tools/lldb-mi/CMakeFiles/lldb-mi.dir/MICmdCmdData.cpp.o -c
/home/sugak/lldb/3.8.0.rc1/src/lldb/tools/lldb-mi/MICmdCmdData.cpp
In file included from
/home/sugak/lldb/3.8.0.rc1/src/lldb/tools/lldb-mi/MICmdCmdData.cpp:45:0:
/home/sugak/lldb/3.8.0.rc1/src/lldb/tools/lldb-mi/MIUtilParse.h:13:39: fatal
error: ../lib/Support/regex_impl.h: No such file or directory
 #include "../lib/Support/regex_impl.h"
   ^
compilation terminated.
```

Looks like `lldb/tools/lldb-mi/MICmdCmdData.cpp` includes a file from llvm
repository, and expects to access it by a relative path from lldb root.

-- 
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] Understanding debugger launch events sequence

[via lldb-dev]

Great, thanks for the confirmation.

Sent from my iPhone

> On Feb 1, 2016, at 1:32 AM, Pavel Labath  wrote:
> 
>> On 29 January 2016 at 18:43, Jeffrey Tan  wrote:
>> Thanks Jim. Is this true for other platforms? Our IDE is going to support
>> Mac and Linux and may extend to Windows some time later.
> 
> AFAIK, windows spawns a separate thread to do the actual debugging,
> but this is hidden from you, and you can carry on debugging normally.
> On Linux/OSX we even spawn a separate process.
> 
> In short, there should be no noticeable user-facing differences
> between the platforms. If you find any, then we'd like to know about
> them.
> 
> pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 26421] New: CommandObjectRegister should set status eReturnStatusSuccessFinishResult

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26421

Bug ID: 26421
   Summary: CommandObjectRegister should set status
eReturnStatusSuccessFinishResult
   Product: lldb
   Version: 3.8
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: git...@newplanetsoftware.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 15791
  --> https://llvm.org/bugs/attachment.cgi?id=15791&action=edit
Suggested patch

CommandObjectRegister::DoExecute() never sets the result status to
eReturnStatusSuccessFinishResult.  It should set this if DumpRegister() returns
true.

-- 
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 26437] New: TestProcessIO.test_stdin_redirection is flaky on android

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26437

Bug ID: 26437
   Summary: TestProcessIO.test_stdin_redirection is flaky on
android
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

(At least) in build 5110 of the ubuntu->android buildbot it failed the start
the inferior.

==
FAIL: test_stdin_redirection_dwo (TestProcessIO.ProcessIOTestCase)
Exercise SBLaunchInfo::AddOpenFileAction() for STDIN without specifying
STDOUT or STDERR.
--
Traceback (most recent call last):
  File
"/home/lldb_build/lldbSlave/lldb-cross-compile/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2299, in dwo_test_method
return attrvalue(self)
  File
"/home/lldb_build/lldbSlave/lldb-cross-compile/llvm/tools/lldb/packages/Python/lldbsuite/test/python_api/process/io/TestProcessIO.py",
line 47, in test_stdin_redirection
self.run_process(False)
  File
"/home/lldb_build/lldbSlave/lldb-cross-compile/llvm/tools/lldb/packages/Python/lldbsuite/test/python_api/process/io/TestProcessIO.py",
line 165, in run_process
self.assertTrue(error.Success(), "Make sure process launched successfully")
AssertionError: False is not True : Make sure process launched successfully
Config=aarch64-/home/lldb_build/Toolchains/aarch64-21/bin/aarch64-linux-android-gcc

The logs seems to indicate that the server returned an error response to the $A
packet. It is hard to diagnose the exact error without access to the server
logs.

-- 
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 26439] New: android adb connection can sometimes fail

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26439

Bug ID: 26439
   Summary: android adb connection can sometimes fail
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

I have observed this happen on the darwin->android buildbot, build #8401


==
FAIL: test_c_global_variables_dwo (TestGlobalVariables.GlobalVariablesTestCase)
   Test 'frame variable --scope --no-args' which omits args and shows scopes.
--
Traceback (most recent call last):
  File
"/Users/lldb_build/lldbSlave/buildDir/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2299, in dwo_test_method
return attrvalue(self)
  File
"/Users/lldb_build/lldbSlave/buildDir/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 617, in wrapper
func(*args, **kwargs)
  File
"/Users/lldb_build/lldbSlave/buildDir/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 617, in wrapper
func(*args, **kwargs)
  File
"/Users/lldb_build/lldbSlave/buildDir/lldb/packages/Python/lldbsuite/test/lang/c/global_variables/TestGlobalVariables.py",
line 44, in test_c_global_variables
'stop reason = breakpoint'])
  File
"/Users/lldb_build/lldbSlave/buildDir/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2677, in expect
self.runCmd(str, msg=msg, trace = (True if trace else False), check = not
error, inHistory=inHistory)
  File
"/Users/lldb_build/lldbSlave/buildDir/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2603, in runCmd
msg if msg else CMD_MSG(cmd))
AssertionError: False is not True : Process should be stopped due to breakpoint
Config=aarch64-/Users/lldb_build/Toolchains/aarch64-21/bin/aarch64-linux-android-gcc


Logs are a bit scarce, but they seem to indicate this was caused by a failed
adb connection while attempting to install liba.so.
1454384745.166052000 [ced5/0713]: 0x7fff5a6affd0
ConnectionFileDescriptor::ConnectionFileDescriptor ()
1454384745.166061000 [ced5/0713]: 0x7fff5a6affd0
ConnectionFileDescriptor::Connect (url = 'connect://localhost:5037')
1454384745.166066000 [ced5/0713]: 0x7fff5a6affd0
ConnectionFileDescriptor::CloseCommandPipe()
1454384745.166078000 [ced5/0713]: 0x7fff5a6affd0
ConnectionFileDescriptor::OpenCommandPipe() - success readfd=16 writefd=17
1454384745.166085000 [ced5/0713]: Socket::TcpConnect (host/port =
localhost:5037)
1454384745.166098000 [ced5/0713]: TCPSocket::Connect (host/port =
localhost:5037)
1454384745.166318000 [ced5/0713]: 0x7fcfec5099d0 Socket::Close (fd = 18)
1454384745.166341000 [ced5/0713]: 0x7fff5a6affd0
ConnectionFileDescriptor::~ConnectionFileDescriptor ()
1454384745.166348000 [ced5/0713]: 0x7fff5a6affd0
ConnectionFileDescriptor::Disconnect ()
1454384745.166353000 [ced5/0713]: 0x7fff5a6affd0
ConnectionFileDescriptor::Disconnect(): Nothing to disconnect
1454384745.166359000 [ced5/0713]: 0x7fff5a6affd0
ConnectionFileDescriptor::CloseCommandPipe()
1454384745.166379000 [ced5/0713]: SBTarget(0x7fcfee005400)::Launch (...) =>
SBProcess(0x7fcfef82ea00)

Normally, the TCPSocket::Connect should be followed by a bunch of socket
traffic. Instead, we seem to be closing the socket without sending any data.

It's hard to tell what to do at the moment, but I'll try to add more logging to
better understand the problem..

-- 
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 26441] New: TestConsecutiveBreakpoints.test_single_step_thread_specific fails on OSX

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26441

Bug ID: 26441
   Summary: TestConsecutiveBreakpoints.test_single_step_thread_spe
cific fails on OSX
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

FAIL: test_single_step_thread_specific
(TestConsecutiveBreakpoints.ConsecutiveBreakpointsTestCase)
   Test that single step stops, even though the second breakpoint is not valid.
--
Traceback (most recent call last):
  File
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 552, in wrapper
return func(self, *args, **kwargs)
  File
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoints/TestConsecutiveBreakpoints.py",
line 96, in test_single_step_thread_specific
self.bkpt_address.GetLoadAddress(self.target))
AssertionError: 4497530763L != 4497530757L


It is not yet clear why r259488 (which fixed the issue on linux and added the
test) does not work on osx.

-- 
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 26441] TestConsecutiveBreakpoints.test_single_step_thread_specific fails on OSX

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26441

Jim Ingham  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jing...@apple.com
 Resolution|--- |FIXED

--- Comment #2 from Jim Ingham  ---
Fixed in r259684.

-- 
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] [cfe-dev] [3.8 Release] Release Candidate 2 source and binaries available

[via lldb-dev]

  Original Message  
From: Renato Golin
Sent: Monday, February 8, 2016 21:13
To: C Bergström
Cc: Hans Wennborg; llvm-dev; release-test...@lists.llvm.org; cfe-dev; 
openmp-dev (openmp-...@lists.llvm.org); LLDB Dev
Subject: Re: [cfe-dev] [lldb-dev] [3.8 Release] Release Candidate 2 source and 
binaries available

On 6 February 2016 at 01:02, C Bergström  wrote:
> I worked on the port of llvm-OpenMP-formally-known-as-Intel to Aarch64
> - can it be included there as well? (I'm not sure what's precisely
> involved - I'm willing to do my best fixing any bugs which pop up -

Hi Chris,

That'd entail me enabling them for AArch64. I have to say, I've done
that a few months ago and it all went smoothly, but I didn't know
anyone was interested (and there were some failures in the OMP tests).

I can enable them on the next release candidate and keep them on for
the next releases, but I can't support it myself, so if you're willing
to handle that, I'm ok with releasing them.

Also, it's not trivial to run the OMP tests, making it a bit harder to
monitor regressions between releases. For now, I'll just build them
and hope you or someone can spot regressions, but ultimately, it'd be
good to have it as part of the release process, maybe inside the
test-suite?

‎

Imho it's critical to get parallel programming working on ARMv8 ( even if it's 
crappy OMP) to start. Please enable it and I'll run the tests against our 
internal QA and we can informally handle testing / guarding against regressions.

Thanks
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 26565] New: test_expr_with_macros_dwarf (TestMacros.TestMacros) failing on FreeBSD 11

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26565

Bug ID: 26565
   Summary: test_expr_with_macros_dwarf (TestMacros.TestMacros)
failing on FreeBSD 11
   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

Command invoked: /usr/home/user/llvm/tools/lldb/test/dotest.py -q --arch=x86_64
--executable /usr/home/user/llvm/build/bin/lldb -s
/usr/home/user/llvm/build/lldb-test-traces -u CXXFLAGS -u CFLAGS -C /usr/bin/cc
--results-port 52272 --inferior -p TestMacros.py
/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test
--event-add-entries worker_index=2:int
FAIL: LLDB (/usr/bin/cc-x86_64) :: test_expr_with_macros_dwarf
(TestMacros.TestMacros)
==
FAIL: test_expr_with_macros_dwarf (TestMacros.TestMacros)
--
Traceback (most recent call last):
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1452, in dwarf_test_method
return attrvalue(self)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/decorators.py",
line 92, in wrapper
func(*args, **kwargs)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/decorators.py",
line 92, in wrapper
func(*args, **kwargs)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/decorators.py",
line 92, in wrapper
func(*args, **kwargs)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/expression_command/macros/TestMacros.py",
line 50, in test_expr_with_macros
self.assertTrue(result.IsValid() and result.GetValue() == "100", "MACRO_1 =
100")
AssertionError: False is not True : MACRO_1 = 100
Config=x86_64-/usr/bin/cc
--
Ran 1 test in 0.248s

Found while getting the tests running again on the FreeBSD buildbot; system
compiler is "FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257)
20150906"

This test does not fail for me on my desktop running a FreeBSD 10.x snapshot
(around FreeBSD 10.3); system compiler is "FreeBSD clang version 3.4.1
(tags/RELEASE_34/dot1-final 208032) 20140512".

-- 
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 26566] New: test_with_run_command_dwarf (TestDataFormatterLibcxxListLoop.LibcxxListDataFormatterTestCase) failing on FreeBS 11

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26566

Bug ID: 26566
   Summary: test_with_run_command_dwarf
(TestDataFormatterLibcxxListLoop.LibcxxListDataFormatt
erTestCase) failing on FreeBS 11
   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

Command invoked: /usr/home/user/llvm/tools/lldb/test/dotest.py -q --arch=x86_64
--executable /usr/home/user/llvm/build/bin/lldb -s
/usr/home/user/llvm/build/lldb-test-traces -u CXXFLAGS -u CFLAGS -C /usr/bin/cc
--results-port 52272 --inferior -p TestDataFormatterLibcxxListLoop.py
/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test
--event-add-entries worker_index=3:int
FAIL: LLDB (/usr/bin/cc-x86_64) :: test_with_run_command_dwarf
(TestDataFormatterLibcxxListLoop.LibcxxListDataFormatterTestCase)
==
FAIL: test_with_run_command_dwarf
(TestDataFormatterLibcxxListLoop.LibcxxListDataFormatterTestCase)
--
Traceback (most recent call last):
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1452, in dwarf_test_method
return attrvalue(self)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/decorators.py",
line 121, in wrapper
func(*args, **kwargs)
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/loop/TestDataFormatterLibcxxListLoop.py",
line 42, in test_with_run_command
self.expect("frame variable *numbers_list", substrs=['[0] = 1', '[1] = 2',
'[2] = 3', '[3] = 4', '[5] = 6'])
  File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1904, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : '[0] = 1' returns expected result
Config=x86_64-/usr/bin/cc


Found while getting the tests running again on the FreeBSD buildbot; system
compiler is "FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257)
20150906"

This test does not fail for me on my desktop running a FreeBSD 10.x snapshot
(around FreeBSD 10.3); system compiler is "FreeBSD clang version 3.4.1
(tags/RELEASE_34/dot1-final 208032) 20140512".

-- 
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 26567] New: Backtrace missing frames while debugging breakpad generated minidump

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26567

Bug ID: 26567
   Summary: Backtrace missing frames while debugging breakpad
generated minidump
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: other
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: joshual...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

I am trying out the minidump target on the windows lldb builds.

My test was to debug a windows minidump generated through breakpad using
lldb/trunk@259885  

I've attached:

   The executable with debug symbols (cross compiled from linux with
mingw-gcc).  This was used to generate the breakpad symbols.

   The minidump generated through breakpad

   The stack trace that I get from lldb

Using breakpad's stackwalk tool I see the following stack trace (truncated)
which has the correct stack trace.

Report ID859ac030
Total Threads43
Processed Threads43
Thread 1 CRASHED [EXCEPTION_ACCESS_VIOLATION_READ @ 0x ]
0x005c1f13(emulator-x86.exe -console.c:2606 )do_crash
0x005be45b(emulator-x86.exe -console.c:427 )control_client_do_command
0x005be713(emulator-x86.exe -console.c:513 )control_client_read_byte
0x005bea56(emulator-x86.exe -console.c:572 )control_client_read
0x00459d65(emulator-x86.exe -Looper.cpp:129 )   
android::qemuQemuLooper::FdWatch::fire
0x0045aac0(emulator-x86.exe -Looper.cpp:329 )   
android::qemuQemuLooper::handleBottomHalf
0x00408942(emulator-x86.exe -async.c:150 )qemu_bh_poll
0x004a2f3a(emulator-x86.exe -main-loop.c:307 )main_loop_wait
0x004a2f83(emulator-x86.exe -main-loop.c:333 )main_loop
0x004bd73a(emulator-x86.exe -vl-android.c:3853 )qemu_main
0x0045c0e6(emulator-x86.exe -main.c:155 )enter_qemu_main_loop
0x007fb32d(emulator-x86.exe -emulator-qt-window.h:64 )   
MainLoopThread::run
0x6696291d(Qt5Core.dll + 0x0002291d )
0x76e67faf(msvcrt.dll + 0x00017faf )
0x76e680f4(msvcrt.dll + 0x000180f4 )
0x75677c03(kernel32.dll + 0x00017c03 )
0x778fad6e(ntdll.dll + 0x0005ad6e )
0x778fad39(ntdll.dll + 0x0005ad39 )
Thread 0
0x778dc9ec(ntdll.dll + 0x0003c9ec )
0x7550dcc2(user32.dll + 0xdcc2 )
0x66b6d1af(Qt5Core.dll + 0x0022d1af )
0x6dee4580(qwindows.dll + 0x00024580 )
0x66b164a5(Qt5Core.dll + 0x001d64a5 )
0x66b1e467(Qt5Core.dll + 0x001de467 )
0x0053d116(emulator-x86.exe -winsys-qt.cpp:115 )   
skin_winsys_enter_main_loop
0x0045e4e5(emulator-x86.exe -main.c:1030 )qt_main
0x0053e997(emulator-x86.exe -winsys-qt.cpp:397 )qMain
0x00402801(emulator-x86.exe -qtmain_win.cpp:113 )WinMain
0x0089f3ec(emulator-x86.exe -crt0_c.c:18 )main
0x00401401(emulator-x86.exe -crtexe.c:315 )__tmainCRTStartup
0x75677c03(kernel32.dll + 0x00017c03 )
0x778fad6e(ntdll.dll + 0x0005ad6e )
0x778fad39(ntdll.dll + 0x0005ad39 )
Thread 2
0x778dc47c(ntdll.dll + 0x0003c47c )
0x77222c01(KERNELBASE.dll + 0x2c01 )
0x005e7637(emulator-x86.exe -ConditionVariable_win32.cpp:91 )   
android::base::ConditionVariable::wait
0x005b4297(emulator-x86.exe -WearAgent.cpp:261 )   
android::wear::WearAgentImpl::connectToAdbHostWorker
0x005b4a84(emulator-x86.exe + 0x001b4a84 )
0x005b5197(emulator-x86.exe -functional:2057 )   
std::_Function_handler::_M_invoke
0x00845ce9(emulator-x86.exe -functional:2471 )   
std::function::operator()
0x005e19c5(emulator-x86.exe -FunctorThread.cpp:29 )   
android::base::FunctorThread::main
0x005e7e0c(emulator-x86.exe -Thread_win32.cpp:127 )   
android::base::Thread::thread_main
0x75677c03(kernel32.dll + 0x00017c03 )
0x778fad6e(ntdll.dll + 0x0005ad6e )
0x778fad39(ntdll.dll + 0x0005ad39 )
Thread 3
0x778dc47c(ntdll.dll + 0x0003c47c )
0x77222c01(KERNELBASE.dll + 0x2c01 )
0x005e7637(emulator-x86.exe -ConditionVariable_win32.cpp:91 )   
android::base::ConditionVariable::wait
0x005dcfcd(emulator-x86.exe -MessageChannel.cpp:51 )   
android::base::MessageChannelBase::beforeRead
0x00823812(emulator-x86.exe -MessageChannel.h:87 )   
android::base::MessageChannel::receive
0x007f9f61(emulator-x86.exe -camera-capture-windows.cpp:905 )   
CameraThread::main
0x005e7e0c(emulator-x86.exe -Thread_win32.cpp:127 )   
android::base::Thread::thread_main
0x75677c03(kernel32.dll + 0x00017c03 )
0x778fad6e(ntdll.dll + 0x0005ad6e )
0x778fad39(ntdll.dll + 0x0005ad39 )

When I use lldb, I get the following backtrace which has some similar frames
but some threads are basically empty.

For example, Thread 2 below is Thread 1 in the above stacktrace due to start at
0 count but there are only kernel frames even though

[lldb-dev] [Bug 26583] New: lldb lacks an equivalent to gdb's "directory" command

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26583

Bug ID: 26583
   Summary: lldb lacks an equivalent to gdb's "directory" command
   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

A FreeBSD user wondered how to achieve the same effect as GDB's "directory"
command in LLDB, and it looks like we don't have an equivalent yet.

Unlike target.source-map which allows a path mapping (useful if e.g. the entire
source tree is available in a different location) the directory command just
controls a list of directories to search by source file base name.

-- 
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 26592] New: [LLDB][MIPS] TestInferiorAssert tests fail if section .gnu_debuglink is not available in libc.so.6

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26592

Bug ID: 26592
   Summary: [LLDB][MIPS] TestInferiorAssert tests fail if section
.gnu_debuglink is not available in libc.so.6
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: nitesh.j...@imgtec.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

The loaded library (like libc.so) may not have its debug version available on
the system (section .gnu_debuglink is not available). The debug version
contains additional symbol information (such as __assert_perror_fail).
Backtrace/function bound fails when symbol information is missing.

-- 
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 26618] New: Not all segment registers are listed in "register read" on Darwin x86_64

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26618

Bug ID: 26618
   Summary: Not all segment registers are listed in "register
read" on Darwin x86_64
   Product: lldb
   Version: 3.7
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: msnk...@mail.ru
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

register read command does not show DS, SS, ES segment registers under Mac OS
X. I think this is a bug in the LLDB code. Or there was reason not to show
them?

-- 
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 26632] New: Breakpoint opcode triggering SIGBUS on Nexus 6

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26632

Bug ID: 26632
   Summary: Breakpoint opcode triggering SIGBUS on Nexus 6
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: e...@codeplay.com
CC: llvm-b...@lists.llvm.org, tbergham...@google.com
Classification: Unclassified

Created attachment 15910
  --> https://llvm.org/bugs/attachment.cgi?id=15910&action=edit
Source and arm binaries

r260367(http://reviews.llvm.org/D16853) which changed the arm breakpoint
opcodes introduced a bug on Nexus 6 Armv7. 
Whenever a breakpoint is hit it triggers a SIGBUS, seen when compiling with
both thumb and 32 bit.

Reverting the commit removes this problem. Note, need to rebuild lldb-server.

Contrived example attached, building source file fact.c using NDK r10e with the
following command lines.

~/Google/arm32_android-toolchain/bin/arm-linux-androideabi-gcc-4.9 fact.c -O0
-marm -fPIE -pie -o fact_32bit.out
~/Google/arm32_android-toolchain/bin/arm-linux-androideabi-gcc-4.9 fact.c -O0
-mthumb -fPIE -pie -o fact_thumb.out


On device
./lldb-server g 127.0.0.1:1234 fact_thumb.out

On host
(lldb) target create ~/Desktop/Scratch/android/fact_thumb.out
Current executable set to '~/Desktop/Scratch/android/fact_thumb.out' (arm).
(lldb) gdb-remote localhost:1234
Process 5109 stopped
* thread #1: tid = 5109, 0xb6f6af88, name = 'fact_thumb.out', stop reason =
signal SIGSTOP
frame #0: 0xb6f6af88
->  0xb6f6af88: movr0, sp
0xb6f6af8c: blx0xb6f71304
0xb6f6af90: movpc, r0
0xb6f6af94: addlt  r11, r4, r0, lsl r5
(lldb) b main
Breakpoint 1: where = fact_thumb.out`main, address = 0xb6fb3370
(lldb) c
Process 5109 resuming
Process 5109 stopped
* thread #1: tid = 5109, 0xb6fb32a0 fact_thumb.out`_start, name =
'fact_thumb.out', stop reason = signal SIGBUS
frame #0: 0xb6fb32a0 fact_thumb.out`_start
fact_thumb.out`_start:
->  0xb6fb32a0 <+0>:  ldrr12, [pc, #0x5c]
0xb6fb32a4 <+4>:  push   {r11, lr}
0xb6fb32a8 <+8>:  ldrr2, [pc, #0x58]
0xb6fb32ac <+12>: addr11, sp, #4

-- 
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