| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
On Windows a process can't delete its own current direcotry, that's why the test
needs to return to the original direcotry before removing newdir.
llvm-svn: 313113
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Test was skipped because -data-evaluate-expression was thought
to not work on globals. This is not the case - the issue was clang
removes debug info for globals in cpp files that are not used.
Add a reference to the globals in question, and fix memory patter in
test to match memory pattern in testcase.
Reviewers: ki.stfu, abidh
Reviewed By: ki.stfu
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D37533
llvm-svn: 312726
|
|
|
|
|
|
|
|
|
| |
This was failing on FreeBSD prior to r312430.
Patch by Vignesh Balu.
Differential Revision: https://reviews.llvm.org/D32522
llvm-svn: 312431
|
|
|
|
|
|
|
| |
I had built without python bindings and did not find this in the grep
output. Adjust the test output for the printing format update.
llvm-svn: 311582
|
|
|
|
|
|
|
|
|
| |
The FXSAVE member `ftw` (FPU Tag Word) was given the wrong size (8-bit)
instead of the correct width (16-bit) as per the x87 Programmer's
Manual. Adjust this to ensure that we print out the complete value for
the register.
llvm-svn: 311579
|
|
|
|
|
|
|
|
|
|
| |
The Linux xfail decorator was removed in r272326 with the claim that the
test "runs reliably on the linux x86 buildbot." It also runs reliably on
FreeBSD for me.
llvm.org/pr25925
llvm-svn: 310644
|
|
|
|
|
|
|
|
|
|
|
| |
This test is consistently reporting unexpected pass for me on FreeBSD
10 and 12. It was failing on the old FreeBSD buildbot which has now been
retired for some time. Will investigate further if this fails once a new
buildbot is configured and running tests.
llvm.org/pr17807
llvm-svn: 310626
|
|
|
|
|
|
|
|
| |
This test passes for me on FreeBSD 10 and 12(-CURRENT).
llvm.org/pr18190
llvm-svn: 310624
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the FreeBSD equivalent of r238549.
This serves 2 purposes:
* LLDB should handle inferior process signals SIGSEGV/SIGILL/SIGBUS/
SIGFPE the way it is suppose to be handled. Prior to this fix these
signals will neither create a coredump, nor exit from the debugger
or work for signal handling scenario.
* eInvalidCrashReason need not report "unknown crash reason" if we have
a valid si_signo
llvm.org/pr23699
Patch by Karnajit Wangkhem
Differential Revision: https://reviews.llvm.org/D35223
llvm-svn: 310591
|
|
|
|
| |
llvm-svn: 310488
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The available platform list was previously only accessible via the
`platform list` command, this patch makes it possible to access that
list via the SBDebugger API. The active platform list has likewise
been exposed via the SBDebugger API.
Differential Revision: https://reviews.llvm.org/D35760
llvm-svn: 310452
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
You can get a breakpoint to auto-continue by adding "continue"
as a command, but that has the disadvantage that if you hit two
breakpoints simultaneously, the continue will force the process
to continue, and maybe even forstalling the commands on the other.
The auto-continue flag means the breakpoints can negotiate about
whether to stop.
Writing tests, I wanted to supply some commands when I made the
breakpoints, so I also added that ability.
llvm-svn: 309969
|
|
|
|
| |
llvm-svn: 309803
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an option was set at on a location, I was just copying the whole option set
to the location, and letting it shadow the breakpoint options. That was wrong since
it meant changes to unrelated options on the breakpoint would no longer take on this
location. I added a mask of set options and use that for option propagation.
I also added a "location" property to breakpoints, and added SBBreakpointLocation.{G,S}etCommandLineCommands
since I wanted to use them to write some more test cases.
<rdar://problem/24397798>
llvm-svn: 309772
|
|
|
|
| |
llvm-svn: 309714
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Implement SBProcessInfo to wrap lldb_private::ProcessInstanceInfo,
and add SBProcess::GetProcessInfo() to retrieve info like parent ID,
group ID, user ID etc. from a live process.
Differential Revision: https://reviews.llvm.org/D35881
llvm-svn: 309664
|
|
|
|
| |
llvm-svn: 309265
|
|
|
|
|
|
|
|
| |
Patch by Jessica Han <jessicah@juniper.net>
https://reviews.llvm.org/D35525
llvm-svn: 309238
|
|
|
|
|
|
| |
rdar://problem/33462362
llvm-svn: 309046
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now -shlib flag can be provided alongside with names of symbols files:
(lldb) target symbols add --shlib stripper-lib.so unstripper-lib.so
This is helpful when default matching mechanisms by name and UUID
can't find a module, and the user needs to explicitly specify
which module the given symbol file belongs to.
Differential Revision: https://reviews.llvm.org/D35607
llvm-svn: 308933
|
|
|
|
| |
llvm-svn: 308919
|
|
|
|
|
|
|
|
| |
This reapplies https://reviews.llvm.org/D35740 with a tweak to find
the section by name rather than type. Section types don't distinguish
between regular sections and their DWO counterparts.
llvm-svn: 308905
|
|
|
|
|
|
| |
This reverts commit r308850.
llvm-svn: 308851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DWO handling code can get confused by clang modules which also use
skeleton CUs to point to the object file with the full debug
info. This patch detects whether an object is a "real" DWO or a clang
module and prevents LLDB from interpreting clang modules as DWO. This
fixes the regression in TestWithModuleDebugging.
http://llvm.org/bugs/show_bug.cgi?id=33875
Differential Revision: https://reviews.llvm.org/D35740
llvm-svn: 308850
|
|
|
|
| |
llvm-svn: 308732
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
SBBreakpointLocation exposed the ignore count, but didn't expose
the hit count. Both values were exposed by SBBreakpoint and
SBWatchpoint, so this makes things a bit more consistent.
Reviewers: lldb-commits
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31283
llvm-svn: 308480
|
|
|
|
| |
llvm-svn: 307943
|
|
|
|
|
|
| |
InstrumentationRuntime breakpoints. (#235)
llvm-svn: 307881
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In NativeProcessLinux::MonitorSIGTRAP we were asserting that the si_code
value is one of the codes we know about. However, that list was very
incomplete -- for example, we were not handling SI_TKILL/SI_USER,
generated by raise(SIGTRAP). A cursory examination show there are at
least a dozen codes like these that an app can generate, and more can be
added at any point.
So, instead of trying to play catchup, I change the default behavior to
treat an unknown si_code like an ordinary signal. The only reason we
needed to inspect si_code in the first place is because
watchpoint/breakpoints are notified as SIGTRAP, but we already know
about those, and us starting to use a new debug event is far less likely
than somebody introducing a new non-debug event.
I add a test case to TestRaise to verify we are handling raise(SIGTRAP)
in an application properly.
llvm-svn: 307644
|
|
|
|
| |
llvm-svn: 307464
|
|
|
|
|
|
|
| |
it fails with go 1.8 and we don't seem to have a maintainer of that
functionality.
llvm-svn: 307391
|
|
|
|
| |
llvm-svn: 307287
|
|
|
|
|
|
|
|
|
|
|
| |
Starting with android ndk r15, clang much more tests are affected by the
-mstackrealign bugl (now nearly all functions are affected, and not just
the ones requiring 16-byte alignment). Due to their numbers, Xfailing
all of them is not a viable option, so we will just have to declare this
configuration unsupported, and wait until ndk ships a clang version that
has this bug fixed.
llvm-svn: 307252
|
|
|
|
|
|
|
|
|
|
| |
to make a target, set a source regex breakpoint, run to
the breakpoint and find the thread that hit the breakpoint.
Start the process of replacing the boiler plate with this
routine.
llvm-svn: 307234
|
|
|
|
|
|
| |
This adds a simple testcase for MainThreadCheckerRuntime. The tool (Main Thread Checker) is only available on Darwin, so the test also detects the presence of libMainThreadChecker.dylib and is skipped if the tool is not available.
llvm-svn: 307170
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All android builds systems have switched to -mstackrealign for building
x86 binaries, so follow their cue with our mini build system.
This presently breaks just one test (TestReturnValue), and this is due
to a compiler bug, which has already been fixed in clang, but it hasn't
made it yet into the official NDK compiler. While I'm touching that
test, I also remove an android-specific XFAIL, which is not relevant
anymore.
llvm-svn: 306683
|
|
|
|
|
|
|
|
| |
Also un-xfailed a testcase that was affected by this. Thanks to Jason Molenda for the patch.
<rdar://problem/32827216>
llvm-svn: 306180
|
|
|
|
|
|
| |
<rdar://problem/32780109>
llvm-svn: 305727
|
|
|
|
|
|
| |
MainThreadCheckerRuntime plugins.
llvm-svn: 305589
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
components to not depend on "." characters in the fileanme
(e.g. "Foundation.framework") but instead to just use path
separators. The names of the files themselves may have dots
in them ("com.apple.sbd") which would break the old scheme.
Also add a test case for this (macosx/find-dsym/bundle-with-dot-in-filename)
as well as a test case for r304520 (macosx/find-dsym/deep-bundle)
which needed a similar setup to test correctly on a single machine.
(both of these are really testing remote debug session situations
where the binary can't be found on the system where lldb is running,
complicating the test case a bit.)
<rdar://problem/31825940>
llvm-svn: 305441
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NSString is loaded from the DWARF, which doesn't have the concept of protocols.
When this is used with the NSMutableDictionary type from Objective-C modules,
this produces errors of the form
error: cannot initialize a parameter of type 'id<NSCopying> _Nonnull' with an rvalue of type 'NSString *'
We're aware of these problems and have an internal bug report filed
(<rdar://problem/32777981>)
llvm-svn: 305424
|
|
|
|
|
|
|
|
| |
The step count depends on code generated by compiler (GCC/Clang).
It will also vary for different MIPS arch variant. Hence skipping these test for MIPS.
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
llvm-svn: 305383
|
|
|
|
|
|
|
| |
bugnumber=llvm.org/pr33452
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
llvm-svn: 305380
|
|
|
|
|
|
|
|
|
| |
Clang does not accept regparm attribute on these platforms.
Fortunately, the default calling convention passes arguments
in registers any way
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
llvm-svn: 305378
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test started being flaky since r303848 (RunThreadPlan: Fix halting
logic in IgnoreBreakpoints = false). I am not reverting that, as I am
confident that actually fixed a problem. A more likely explanation is
that there is still one corner case that is not handled correctly there.
Marking the test as flaky until I get a chance to investigate. I also
mark the test as no-debug-info-dependend -- it stresses expression
evaluation, as far as debug info goes, the test if extremely simple.
llvm-svn: 305286
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces a new thread backtrace command "unique".
The command is based off of "thread backtrace all" but will instead
find all threads which share matching call stacks and de-duplicate
their output, listing call stack and all the threads which share it.
This is especially useful for apps which use thread/task pools
sitting around waiting for work and cause excessive duplicate output.
I needed this behavior recently when debugging a core with 700+ threads.
Differential Revision: https://reviews.llvm.org/D33426
Reviewers: clayborg, jingham
Patch by Brian Gianforcaro <b.gianfo@gmail.com>
llvm-svn: 305197
|
|
|
|
|
|
|
|
| |
I was over-eager to unable this test in r304976. It still fails in this
combination, at there does not seem to be anything we can do about it,
as the generated code does not preserve the link register.
llvm-svn: 305062
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When a call instruction is the last instruction in a function, the
backtrace PC will point past the end of the function. We already had
special code to handle that, but we did not handle the case where the PC
ends up outside of the bounds of the module containing the function,
which is a situation that occured in TestNoreturnUnwind on android for
some arch/compiler combinations.
I fix this by adding an argument to Address resolution code which states
that we are ok with addresses pointing to the end of a module/section to
resolve to that module/section.
I create a reproducible test case for this situation by hand-crafting an
executable which has a noreturn function at the end of a module.
Reviewers: jasonmolenda, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32022
llvm-svn: 304976
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When parsing types originating in modules, it is possible to encounter AttributedTypes
(such as the type generated for NSString *_Nonnull). Some of LLDB's ClangASTContext
methods deal with them; others do not. In particular, one function that did not was
GetTypeInfo, causing TestObjCNewSyntax to fail.
This fixes that, treating AttributedType as essentially transparent and getting the
information for the modified type.
In addition, however, TestObjCNewSyntax is a monolithic test that verifies a bunch of
different things, all of which can break independently of one another. I broke it
apart into smaller tests so that we get more precise failures when something (like
this) breaks.
Differential Revision: https://reviews.llvm.org/D33812
llvm-svn: 304510
|
|
|
|
|
|
|
|
|
| |
This works on SVN but is a bit fragile on the Swift branch.
I'm adding the test to both, so we have this path covered.
<rdar://problem/32372372>
llvm-svn: 304314
|