| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
ensure we don't regress on this.
A recent POSIX host thread issue where HostThreadPosix::Join() wasn't returning the thread result was responsible for this regression, yet we had no test case covering this so it wasn't discovered.
llvm-svn: 225284
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
TestCompletion was broken for Ubuntu (and probably for Debian also).
The issue was that the lldb prompt in color (which is the default
behavior) was confusing pexpect.
Test Plan: "http://199.223.233.39:8011/lldb-try-clang-build-clang-test/"
Reviewers: zturner, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6671
llvm-svn: 224642
|
|
|
|
|
|
|
|
|
|
| |
clang does not yet support MS-ABI record layout for externally-sourced
ASTs. As a result, attempting to format something that requires data
layout results in undefined behavior in clang, in this case an assert.
http://llvm.org/pr21800 tracks fixing this on the clang side.
llvm-svn: 223868
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Getting this working correctly is a significant amount of work.
Assertions on Windows show up as error code 0xC0000409, which is
STATUS_STACK_BUFFER_OVERRUN. In order to accurately determine
that this is not just any stack buffer overrun, but one triggered
by a call to abort, we would need to analyze the call stack. This
in turn requires better symbol support for Windows executables,
and work on LLDB to make stack frames better on Windows.
For now, these are XFAIL'ed and tracked in http://llvm.org/pr21793.
llvm-svn: 223816
|
|
|
|
| |
llvm-svn: 223731
|
|
|
|
| |
llvm-svn: 223700
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following lldb unit tests fail check-lldb on ubuntu:
TestDataFormatterStdMap.py
TestDataFormatterStdVBool.py
TestDataFormatterStdVector.py
TestDataFormatterSynthVal.py
TestEvents.py
TestInitializerList.py
TestMemoryHistory.py
TestReportData.py
TestValueVarUpdate.py
These unit test failures are for non-core functionality. The intent is to
reduce the check-lldb FAILS to core functionality FAILS and then circle
back later and fix these FAILS at a later date.
llvm-svn: 222608
|
|
|
|
| |
llvm-svn: 222589
|
|
|
|
| |
llvm-svn: 222449
|
|
|
|
|
|
|
|
|
|
| |
Process/ProcessPOSIX.cpp
and FreeBSD/ProcessMonitor.
http://reviews.llvm.org/D6240
llvm-svn: 222372
|
|
|
|
|
|
| |
options, we don't end up caching the summary hence obtained. You may want to obtain an uncapped summary, but this should not be reflected in the summary we cache. The drawback is that we don't cache as aggressively as we could, but at least you get to have different summaries with different options without having to reset formatters or the SBValue at each step
llvm-svn: 222280
|
|
|
|
|
|
| |
retrieve uncapped data
llvm-svn: 222277
|
|
|
|
| |
llvm-svn: 222246
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem is that editline currently is trying to be smart when we paste things into a terminal window. It detects that input is pending and multi-line input is accepted as long as there is anything pending.
So if you open lldb and paste the text between the quotes:
"command regex carp
s/^$/help/
carp
"
We still still be stuck in the "command regex" multi-line input reader as it will have all three lines:
"s/^$/help/
carp
"
The true fix for this is something Kate Stone will soon work on:
- multi-line input readers must opt into this paste/pending input feature ("expr" will opt into it, all other commands won't)
- If we are in a multi-line input reader that requests this and stuff is pasted, then it will do what it does today
- if we start in a IOHandler that doesn't need/want pending input and text is pasted, and we transistion to a IOHandler that does want this functionality, then disable the pending input. Example text would be:
"frame variable
thread backtrace
expr
for (int i=0;i<10;++i)
(int)printf("i = %i\n", i);
frame select 0
"
When we push the expression multi-line reader we would disable the pending input because we had pending input _before_ we entered "expr".
If we did this first:
(lldb) expr
Then we pasted:
"void foo()
{
}
void bar()
{
}
"
Then we would allow the pending input to not look for an empty line to terminate the expression. We filed radar 19008425 to track fixing this issue.
llvm-svn: 222206
|
|
|
|
|
|
|
|
|
|
|
| |
Part of TestConcurrentEvents starts threads that are supposed to be
delayed by one second.
Test was adding "delay" threads to the "actions" thread list instead
of the "delay_actions" list, which caused them to be started without
delay.
llvm-svn: 221859
|
|
|
|
|
|
| |
eligible for oneline printing, and fixes rdar://18120906
llvm-svn: 221701
|
|
|
|
|
|
|
|
| |
r221575 introduced a NoreturnUnwind test that did not skip the dsym
test on non-darwin platforms, and had the @dwarf_test case as an exact
copy of the dsym case (including the test name, test_with_dsym).
llvm-svn: 221611
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a noreturn function was the last function in a section,
we wouldn't correctly back up the saved-pc value into the
correct section leading to us showing the wrong function in
the backtrace.
Also add a backtrace test with an attempt to elicit this
particular layout. It happens to work out with clang -Os
but other compilers may not quite get the same layout I'm
getting at that opt setting. We'll still be exercising the
basic noreturn handling in the unwinder even if we don't get
one function at the very end of a section.
<rdar://problem/16051613>
llvm-svn: 221575
|
|
|
|
|
|
| |
allowing a hook to be passed back the test instance, were it not to be already bound to self. Use this ability to make the reversal of escape-non-printables a teardown hook for added reliability of the testing logic
llvm-svn: 221402
|
|
|
|
|
|
|
|
|
|
|
| |
should or should not escape sequences such as \t, \n, .. and generally any non-printing character
The recent StringPrinter changes made this behavior the default, and the setting defaults to yes
If you want to change this behavior and see non-printables unescaped (e.g. "a\tb" as "a b"), set it to false
Fixes rdar://12969594
llvm-svn: 221399
|
|
|
|
|
|
| |
get hit so it doesn't intermittently fail on MacOSX.
llvm-svn: 221201
|
|
|
|
|
|
| |
llvm.org/pr21411
llvm-svn: 220856
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Python summary functions
This works similarly to the {thread/frame/process/target.script:...} feature - you write a summary string, part of which is
${var.script:someFuncName}
someFuncName is expected to be declared as
def someFuncName(SBValue,otherArgument) - essentially the same as a summary function
Since . -> [] are the only allowed separators, and % is used for custom formatting, .script: would not be a legitimate symbol anyway, which makes this non-ambiguous
llvm-svn: 220821
|
|
|
|
|
|
| |
canonical type, since that will strip typedefs where we want them to be preserved. Fixes rdar://15453076
llvm-svn: 220810
|
|
|
|
| |
llvm-svn: 220743
|
|
|
|
| |
llvm-svn: 220661
|
|
|
|
| |
llvm-svn: 220660
|
|
|
|
|
|
|
|
| |
All of these test fixups are prep work for when llgs is
running with llgs for local process debugging, where these
tests fail without the ptracer lock-down suppression.
llvm-svn: 220656
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to previous fix, this augments the test inferior to
immediately indicate it may be ptraced by any Linux process
when the appropriate symbols are defined.
This seems to indicate we need to fix our lldb attach logic to
catch when an attach fails, and trigger an appropriate error
instead of the current behavior of hanging indefinitely.
llvm-svn: 220654
|
|
|
|
|
|
| |
chance due to inlining. Set breakpoints where you want them instead. Fixes rdar://18724175
llvm-svn: 220513
|
|
|
|
|
|
| |
CXXFormattersFunction.h. Also, add a synthetic child provider for libc++'s version of std::initializer_list<T>
llvm-svn: 220421
|
|
|
|
|
|
| |
value as part of themselves
llvm-svn: 220414
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BreakpointLocation::ShouldStop. That worked but wasn't really right,
since there's nothing to guarantee that won't get called more than
once. So this change moves that responsibility to the StopInfoBreakpoint
directly, and then it uses the BreakpointSite to actually do the bumping.
Also fix a test case that was assuming if you had many threads running some
code with a breakpoint in it, the hit count when you stopped would always be
1. Many of the threads could have hit it at the same time...
<rdar://problem/18577603>
llvm-svn: 220358
|
|
|
|
|
|
| |
This used to be optional, but that makes it harder to track what tests are failing for what reason. So, make it mandatory, in the form of refusing to run the test suite if annotations are missing
llvm-svn: 220012
|
|
|
|
| |
llvm-svn: 220003
|
|
|
|
|
|
| |
changes
llvm-svn: 219828
|
|
|
|
|
|
|
|
|
|
| |
The build fails due to missing asan runtime in the FreeBSD base system.
Instead of marking it expected fail, just skip until we have the runtime
available.
llvm.org/pr21136
llvm-svn: 219701
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
report data extraction
Reviewed at http://reviews.llvm.org/D5592
This patch gives LLDB some ability to interact with AddressSanitizer runtime library, on top of what we already have (historical memory stack traces provided by ASan). Namely, that's the ability to stop on an error caught by ASan, and access the report information that are associated with it. The report information is also exposed into SB API.
More precisely this patch...
adds a new plugin type, InstrumentationRuntime, which should serve as a generic superclass for other instrumentation runtime libraries, these plugins get notified when modules are loaded, so they get a chance to "activate" when a specific dynamic library is loaded
an instance of this plugin type, AddressSanitizerRuntime, which activates itself when it sees the ASan dynamic library or founds ASan statically linked in the executable
adds a collection of these plugins into the Process class
AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan
this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo
the StopInfo superclass is extended with a m_extended_info field (it's a StructuredData::ObjectSP), that can hold arbitrary JSON-like data, which is the way the new plugin provides the report data
the "thread info" command now accepts a "-s" flag that prints out the JSON data of a stop reason (same way the "-j" flag works now)
SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream
adds a test case for all of this
I plan to also get rid of the original ASan plugin (memory history stack traces) and use an instance of AddressSanitizerRuntime for that purpose.
Kuba
llvm-svn: 219546
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
output style can be customized. Change the built-in default to be
more similar to gdb's disassembly formatting.
The disassembly-format for a gdb-like output is
${addr-file-or-load} <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>:
The disassembly-format for the lldb style output is
{${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:\n}{${function.changed}\n{${module.file.basename}`}{${function.name-without-args}}:\n}{${current-pc-arrow} }{${addr-file-or-load}}:
The two backticks in the lldb style formatter triggers the sub-expression evaluation in
CommandInterpreter::PreprocessCommand() so you can't use that one as-is ... changing to
use ' characters instead of ` would work around that.
<rdar://problem/9885398>
llvm-svn: 219544
|
|
|
|
|
|
| |
to generate a value for itself, that's not a disqualifier from one-line printing. Also, fetch synthetic values if available and requested for children as well while printing them
llvm-svn: 219427
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GetValueAsUnsigned(), GetValueAsCString() would return)
The way to do this is to write a synthetic child provider for your type, and have it vend the (optional) get_value function.
If get_value is defined, and it returns a valid SBValue, that SBValue's value (as in lldb_private::Value) will be used as the synthetic ValueObject's Value
The rationale for doing things this way is twofold:
- there are many possible ways to define a "value" (SBData, a Python number, ...) but SBValue seems general enough as a thing that stores a "value", so we just trade values that way and that keeps our currency trivial
- we could introduce a new level of layering (ValueObjectSyntheticValue), a new kind of formatter (synthetic value producer), but that would complicate the model (can I have a dynamic with no synthetic children but synthetic value? synthetic value with synthetic children but no dynamic?), and I really couldn't see much benefit to be reaped from this added complexity in the matrix
On the other hand, just defining a synthetic child provider with a get_value but returning no actual children is easy enough that it's not a significant road-block to adoption of this feature
Comes with a test case
llvm-svn: 219330
|
|
|
|
|
|
|
|
|
|
| |
The build fails due to missing asan runtime in the FreeBSD base system.
Instead of marking it expected fail, just skip until we have the runtime
available.
llvm.org/pr21136
llvm-svn: 219328
|
|
|
|
|
|
|
|
|
|
|
|
| |
the default search method is "always" as of r218405.
For the purposes of this test, set it back to "headers"
to confirm that the file+line breakpoint doesn't work,
then verify that it does work with "always". Leave it
in "always" setting.
<rdar://problem/18564244>
llvm-svn: 219251
|
|
|
|
|
|
| |
The failure and the bug are entirely unrelated, and it's trivial to write a repro case for that bug anyway, so no need to use this complicated test case
llvm-svn: 219248
|
|
|
|
| |
llvm-svn: 219148
|
|
|
|
|
|
| |
lines at arbitrary points.
llvm-svn: 219133
|
|
|
|
|
|
| |
FreeBSD comes with libc++. Skip them
llvm-svn: 219032
|
|
|
|
|
|
| |
Darwin, or clang where applicable. Non-Apple folks, if these fail for you, maybe we can put some more helpful markers on them
llvm-svn: 219020
|
|
|
|
|
|
| |
that matter, also skip running the test on Darwin. libstdc++ is more relevant on non-Apple platforms
llvm-svn: 218952
|
|
|
|
| |
llvm-svn: 218908
|