| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
shared libraries.
The issue was we were sending a "qSymbol::" packet and it we were already disconnected were weren't exiting the while loop if we didn't successfully send the qSymbol packet.
<rdar://problem/22098746>
llvm-svn: 244683
|
| |
|
|
|
|
| |
http://reviews.llvm.org/D8712
llvm-svn: 244681
|
| |
|
|
|
|
|
|
| |
This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types to be able to use a type system.
All tests pass on MacOSX and passed on linux the last time this was submitted.
llvm-svn: 244679
|
| |
|
|
|
|
|
|
| |
- TestLldbGdbServer.py both clang & gcc, i386 and x86_64
- TestConstVariables.py gcc, i386 and x86_64
- 112 failures clang, i386
llvm-svn: 244514
|
| |
|
|
|
|
|
|
|
|
|
|
| |
contained within Process so that we won't be duplicating the warning
message if other parts of the code want to issue the message. Change
Process::PrintWarning to be a protected method - the public method
will be the PrintWarningOptimization et al. Also, Have
Thread::FunctionOptimizationWarning shortcut out if the warnings
have been disabled so that we don't (potentially) compute parts of
the SymbolContext unnecessarily.
llvm-svn: 244436
|
| |
|
|
|
|
| |
http://reviews.llvm.org/D11256
llvm-svn: 244419
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mode support
This change :
- Fixes offsets of all register sets for Mips.
- Adds MSA register set and FRE=1 mode support for FP register set.
- Separates lldb register numbers and register infos of freebsd/mips64 from linux/mips64.
- Re-orders the register numbers of all kinds for mips to be consistent with freebsd order of register numbers.
- Eliminates ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and uses llvm::APInt and llvm::APFloat for all integer and floating point types.
Reviewers : emaste, jaydeep, clayborg
Subscribers : emaste, mohit.bhakkad, nitesh.jain, bhushan
Differential : http://reviews.llvm.org/D10919
llvm-svn: 244308
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
per Module instead of once per CompileUnit, and print the
module name. A module may have a mix of compile units built with
optimization and compile units built without optimization -- the
warning won't be printed until the user selects a stack frame of
a function that was built with optimization. And as before, it
will only be printed once per module per debug session.
<rdar://problem/19281172>
llvm-svn: 244281
|
| |
|
|
| |
llvm-svn: 244194
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first part was in r243508 -- the extent of the UI changes in that
patchset was to add "[opt]" to the frame-format when a stack frame was
built with optimized code.
In this change, when a stack frame built with optimization is selected,
a message will be printed to the async output channel --
opt1.c was compiled with optimization - stepping may behave oddly; variables may not be available.
The warning will be only be printed once per source file in a debug session.
These warnings may be disabled by
settings set target.process.optimization-warnings false
Internally, a new Process::PrintWarning() method has been added for
warnings that we want to print only once to the user. It takes a type
of warning (currently only eWarningsOptimization) and an object
pointer (CompileUnit*) - the warning will only be printed once for a
given object pointer value.
This is a bit of a prototype of this change - I think we will be
tweaking it more in the future. But I wanted to land this and see
how it goes. Advanced users will find these warnings unnecessary
noise and will quickly disable them - but anyone who maintains a
debugger knows that debugging optimized code, without realizing it,
is a constant source of confusion and frustation for more typical
debugger users.
I imagine there will be more of these "warn once per whatever" style
warnings that we will want to add in the future and we'll need to
come up with a better way for enabling/disabling them. But I'm not
srue what form that warning settings should take and I didn't want
to code up something that we regret later, so for now I just added
another process setting for this one warning.
<rdar://problem/19281172>
llvm-svn: 244190
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: loladiro, jingham, emaste, zturner, brucem
Subscribers: tberghammer, danalbert, srhines, zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D11717
llvm-svn: 244039
|
| |
|
|
|
|
| |
The SB API for major version 340 won't be changing any more.
llvm-svn: 243943
|
| |
|
|
|
|
|
| |
r243914 introduced a change which mistakenly tried to build the
Windows minidump code on all platforms rather than only on Windows.
llvm-svn: 243941
|
| |
|
|
|
|
| |
http://reviews.llvm.org/D11611
llvm-svn: 243914
|
| |
|
|
|
|
| |
'memory find' takes
llvm-svn: 243902
|
| |
|
|
| |
llvm-svn: 243893
|
| |
|
|
|
|
|
|
|
|
| |
working with (the Communication m_bytes ivar) contained a single packet.
Instead, it may contain multitudes. Find the boundaries of the first packet
in the buffer and replace that with the decompressed version leaving the
rest of the buffer unmodified.
<rdar://problem/21841377>
llvm-svn: 243846
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
On FreeBSD the tid is (somewhat unintuitively) found in the pr_pid
field of the NT_PRSTATUS note. Collect it when parsing the note and
store it in the thread data.
For Linux I've left the original behaviour of using sequential TIDs
(0, 1, 2...) as I don't yet have code to obtain it.
Differential Revision: http://reviews.llvm.org/D11652
llvm-svn: 243748
|
| |
|
|
|
|
|
|
| |
is optimized into DWARFCompileUnit, where it should have
been. Next I'll need to call this from another section
of code for DWARF-in-.o-file behavior correctness.
llvm-svn: 243736
|
| |
|
|
|
|
| |
the actions taken when trying to locate binaries.
llvm-svn: 243732
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11667
llvm-svn: 243716
|
| |
|
|
| |
llvm-svn: 243697
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously embedded interpreters were handled as ad-hoc source
files compiled into source/Interpreter. This made it hard to
disable a specific interpreter, or to add support for other
interpreters and allow the developer to choose which interpreter(s)
were enabled for a particular build.
This patch converts script interpreters over to a plugin-based system.
Script interpreters now live in source/Plugins/ScriptInterpreter, and
the canonical LLDB interpreter, ScriptInterpreterPython, is moved there
as well.
Any new code interfacing with the Python C API must live in this location
from here on out. Additionally, generic code should never need to
reference or make assumptions about the presence of a specific interpreter
going forward.
Differential Revision: http://reviews.llvm.org/D11431
Reviewed By: Greg Clayton
llvm-svn: 243681
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If we used unnamed pipes instead of named pipes, we can avoid having the
file system littered with debugserver-named-pipes if lldb-server happens to
crash for whatever reason. Also, on some buggy systems, it's possible to be
able to create but not to delete a fifo. Ideally, support for unnamed pipes
should be added to debugserver as well, so we can avoid the `#ifdef` here.
Reviewers: clayborg, vharron, chying
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11609
llvm-svn: 243667
|
| |
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D11595
llvm-svn: 243637
|
| |
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain
Reviewers: clayborg, ovyalov.
Subscribers: jaydeep, bhushan, mohit.bhakkad, sagar, emaste, lldb-commits.
Differential Revision: http://reviews.llvm.org/D11176
llvm-svn: 243620
|
| |
|
|
|
|
|
|
|
|
|
| |
SUMMARY:
The patch creates Unix Signals based on target architecture. For MIPS it creates MipsLinuxSignals.
Reviewers: clayborg
Subscribers: mohit.bhakkad, sagar, lldb-commits
Differential Revision: http://reviews.llvm.org/D11455
llvm-svn: 243618
|
| |
|
|
|
|
|
|
| |
plugin.symbol-file.dwarf.comp-dir-symlink-paths setting.
http://reviews.llvm.org/D11586
llvm-svn: 243580
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SourceManager::GetFile() in case APIs are called that don't update the source.
The following functions were the only functions that updates the source file:
SourceManager::File::DisplaySourceLines()
SourceManager::File::FindLinesMatchingRegex()
But there we API calls that were using the SourceManager::File and asking it questions, like "is line 12 valid" and that might respond incorrectly if the source file had been updated.
<rdar://problem/21269402>
llvm-svn: 243551
|
| |
|
|
|
|
|
|
|
|
| |
owners list, so the StopInfo machinery can get the list of owners without
some other thread being able to mess up the list by deleting/disabline one of its
locations in the process of doing so.
<rdar://problem/18685197>
llvm-svn: 243541
|
| |
|
|
| |
llvm-svn: 243521
|
| |
|
|
| |
llvm-svn: 243520
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit moves the m_spawned_pids member from the common LLGS/Platform class to the plaform
specific part. This enables us to remove LLGS code, which was attempting to manage the
m_spawned_pids contents, but at the same time making sure, there is only one debugged process. If
we ever want to do multi-process debugging, we will probably want to replace this with a set of
NativeProcessProtocolSP anyway. The only functional change is that support for
qKillSpawnedProcess packet is removed from LLGS, but this was not used there anyway (we have the
k packet for that).
Reviewers: ovyalov, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11557
llvm-svn: 243513
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
system, make a couple of additional checks to see if the
attach was denied via the System Integrity Protection that
is new in Mac OS X 10.11. If so, return a special E87
error code to indicate this to lldb.
Up in lldb, if we receive the E87 error code, be specific
about why the attach failed.
Also detect the more common case of general attach failure
and print a better error message than "lost connection".
I believe this code will all build on Mac OS X 10.10 systems.
It may not compile or run on earlier versions of the OS.
None of this should build on other non-darwin systems.
llvm-svn: 243511
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
debugging optimized code. Adds new methods on Function/SBFunction
to query whether a given function is optimized. Adds a new
function.is-optimized format entity and changes the default
frame-format to append "[opt]" if the function was built with
optimization.
The only indication that a binary was built with optimization
that we have right now is the presence of the DW_AT_APPLE_optimized
attribute (DW_FORM_flag value 1) in the DW_TAG_compile_unit.
The absence of this flag may mean that the compile_unit was not
compiled with optimization, or it may mean that the producer
does not generate this attribute.
Currently this only works for dSYM debugging. When we create
the CompileUnit with dwarf-in-.o-file debugging we don't have
the attribute value yet so it's not set. I need to find the
flag value when we do start to read the .o file DWARF and
set the CompileUnit's status at that point - but haven't
done it yet.
I'm also going to add a mechanism for issuing warnings to users
such that they're only issued once in a debug session and
there is away for users to suppress these warnings altogether
via .lldbinit file settings. But I want to get this changeset
committed now that it's at a useful state.
<rdar://problem/19281172>
llvm-svn: 243508
|
| |
|
|
|
|
|
|
|
|
| |
counts. If you delete a breakpoint belonging to a site just as you are
processing a hit on that site, you could cause the BreakpointSite loop to
access a now deleted location.
<rdar://problem/19310323>
llvm-svn: 243507
|
| |
|
|
| |
llvm-svn: 243482
|
| |
|
|
|
|
|
|
| |
cache correctly on update, causing stale children to be returned in some circumstances
Fixes rdar://20560680
llvm-svn: 243472
|
| |
|
|
|
|
|
|
| |
The removal of in-process Linux debug support left a switch statement
with llvm::Triple::FreeBSD as the only case. Simplify by replacing it
with a now-equivalent assertion.
llvm-svn: 243468
|
| |
|
|
|
|
|
| |
FreeBSD thread information is updated after stop - we do not use a
message for thread creation.
llvm-svn: 243448
|
| |
|
|
| |
llvm-svn: 243428
|
| |
|
|
|
|
|
|
|
| |
As of r240543 ProcessPOSIX and POSIXThread are used only on FreeBSD, so
just roll them into ProcessFreeBSD and FreeBSDThread.
Differential Revision: http://reviews.llvm.org/D10698
llvm-svn: 243427
|
| |
|
|
|
|
|
|
| |
patch by Eugene Zelenko
Differential Revision: http://reviews.llvm.org/D11429
llvm-svn: 243399
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Handle_k was printing an error when killing a process because KillSpawnedProcess was expecting to
be asynchronously notified of the process death, which no longer works, since we don't wait for
the process on a separate thread. However, the whole usage of KillSpawnedProcess is dubious here,
since it tries to be nice and terminate the process first with SIGTERM, which will not have the
intended effect on a ptraced process. I replace this code with a call to
NativeProcessProtocol::Kill, which does not suffer from these problems.
Reviewers: chaoren, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11520
llvm-svn: 243397
|
| |
|
|
| |
llvm-svn: 243369
|
| |
|
|
|
|
|
|
| |
ValueObjectChild::CanUpdateWithInvalidExecutionContext()
This one should prevent the previous issues, and be the one true fix for rdar://21949558
llvm-svn: 243367
|
| |
|
|
|
|
|
|
| |
segments and classify them correctly.
<rdar://problem/20942073>
llvm-svn: 243344
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11540
llvm-svn: 243333
|
| |
|
|
|
|
| |
separator, but just a part of the path (e.g. /tmp/fi:lename vs. pro:/tmp/fi:lename)
llvm-svn: 243330
|
| |
|
|
|
|
| |
expansion. NFC.
llvm-svn: 243301
|