| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See http://reviews.llvm.org/D5108 for details.
This change does the following:
* eliminates the Process::GetUnixSignals() virtual method and replaces with a fixed getter.
* replaces the Process UnixSignals storage with a shared pointer.
* adds a Process constructor variant that can be passed the UnixSignalsSP. When the constructor without the UnixSignalsSP is specified, the Host's default UnixSignals is used.
* adds a host-specific version of GetUnixSignals() that is used when we need the host's appropriate UnixSignals variant.
* replaces GetUnixSignals() overrides in PlatformElfCore, ProcessGDBRemote, ProcessFreeBSD and ProcessLinux with code that appropriately sets the Process::UnixSignals for the process.
This change also enables some future patches that will enable llgs to be used for local Linux debugging.
llvm-svn: 216748
|
| |
|
|
| |
llvm-svn: 216630
|
| |
|
|
|
|
|
| |
This updates the DWARF language identifiers to include recent additions to
the DWARF 5 specification (draft).
llvm-svn: 216486
|
| |
|
|
| |
llvm-svn: 216210
|
| |
|
|
|
|
|
|
|
|
| |
than one architecture select a compatible platform if all architectures match the same platform.
This helps us "do the right thing" when loading a file without having to specify an architecture.
<rdar://problem/18021558>
llvm-svn: 216115
|
| |
|
|
|
|
|
|
| |
As a side effect, this patch also eliminates all of the
preprocessor conditionals previously used to implement
GetArchitecture().
llvm-svn: 216074
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
What it does:
- it introduces a concept of EncodingToType to the ObjCLanguageRuntime
The ObjC runtime has a "type encoding" feature that describes types as strings
The EncodingToType is a decoder for that format, making types out of type encoding strings
This feature already existed in some shape as we were using it to create method signatures out of the runtime, but this checkin extends the parser to support the full syntax, and moves things so that more parts of LLDB have access to this decoder
- it splits the ClassDescriptorV2 object to its own file, it was starting to grow too large
- it adds to the ClassDescriptor mechanism a notion of ivar storage; the ObjC runtime vends ivar information as well as method information
While ivar information is not ready for prime type (i.e. we don't want to add it to the runtime generated types for expression evaluator usage), there are potentially useful scenarios in which realizing ivar types could be useful. For now, the ClassDescriptor is going to hold ivar information directly. Existing code already allows describing ivars, this patch hooks those moving parts up so that one can actually ask a ClassDescriptor about ivars for the class it represents
and as a couple minor niceties:
- it makes it possible to retrieve the LLDB ClangASTContext that is associated to a clang::ASTContext
- it extends the ValueObject-to-ClassDescriptor API in the language runtime to deal correctly with base-class hierarchies
llvm-svn: 216026
|
| |
|
|
|
|
| |
This change modifies the 'process launch' --disable-aslr option to take a boolean argument. If the user directly specifies --disable-aslr {true,false}, that setting will control whether the process is launched with ASLR disabled accordingly. In the event that the setting is not explicitly made on the process launch command line, then the value is retrieved from the target.disable-aslr setting (i.e. settings show target.disable-aslr).
llvm-svn: 215996
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch creates a HostInfo class, a static class used to answer
basic queries about the host platform. As part of this change,
some functionality is moved from Host to HostInfo, and relevant
fixups are performed in the rest of the codebase.
This is part of a larger effort to isolate more code in the Host
layer into platform-specific groups, to make it easier to make
platform specific changes for a particular Host without breaking
other hosts.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D4963
llvm-svn: 215992
|
| |
|
|
|
|
| |
does some textual replacements. However, if one were unaware of this, they might name their script using the 'untampered' file name and they would get no feedback about it. Add logic to LLDB to make sure we tell people about those changes if it turns out they might need to know. Fixes rdar://14310572
llvm-svn: 215798
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
More specifically, this change can be summarized as follows:
1) Makes an lldbHostPosix library which contains code common to
all posix platforms.
2) Creates Host/FileSystem.h which defines a common FileSystem
interface.
3) Implements FileSystem.h in Host/windows and Host/posix.
4) Creates Host/FileCache.h, implemented in Host/common, which
defines a class useful for storing handles to open files needed
by the debugger.
Differential Revision: http://reviews.llvm.org/D4889
llvm-svn: 215775
|
| |
|
|
|
|
|
|
| |
Made Process::Attach list the matching processes if there is more than one match.
<rdar://problem/18023352>
llvm-svn: 215730
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
FileAction was previously a nested class in ProcessLaunchInfo.
This led to some unfortunate style consequences, such as requiring
the AddPosixSpawnFileAction() funciton to be defined in the Target
layer, instead of the more appropriate Host layer. This patch
makes FileAction its own independent class in the Target layer,
and then moves AddPosixSpawnFileAction() into Host as a result.
Differential Revision: http://reviews.llvm.org/D4877
llvm-svn: 215649
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
you do:
% lldb -x /bin/ls
(lldb) r
(lldb) r
Prior to this fix the first time it would run /usr/bin/arch with "-arch x86_64" the first time and succeed, and fail the second when the target had updated its architecture to x86_64h. We can't specify x86_64h to /usr/bin/arch, it doesn't handle it.
Also fixed it so /usr/bin/arch is only used for Apple triples.
<rdar://problem/17951312>
llvm-svn: 215475
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This issue caused the lldb prompt to not show up in certain cases, very
noticeable on Linux systems.
See details on this review:
http://reviews.llvm.org/D4863
And on this lldb-commits thread:
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140811/012306.html
Change by Shawn Best.
(Much useful help and testing by the rest of the community, thanks all!)
llvm-svn: 215446
|
| |
|
|
| |
llvm-svn: 215411
|
| |
|
|
|
|
| |
This all appears to have been dead, unnecessary code.
llvm-svn: 215405
|
| |
|
|
|
|
|
|
| |
* transfered => transferred
* unkown => unknown
* sucessfully => successfully
llvm-svn: 215367
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
allocation range
in all but one of the AllocatedBlocks that matched the requested permissions.
Over time this would make the performance of expressions slow down considerably.
Also added a little bit of logging that was helpful in resolving the issue.
<rdar://problem/17954438>
llvm-svn: 215239
|
| |
|
|
|
|
|
|
| |
ThreadPlanShouldStopHere::DefaultShouldStopHereCallback
in the ThreadPlanStepInRange's implementation, just call it...
llvm-svn: 215178
|
| |
|
|
| |
llvm-svn: 215124
|
| |
|
|
|
|
|
|
|
|
| |
the same parent frame, but different current frame - e.g. when
you step past a tail call exit from a function. Apply the same
"avoid-no-debug" rules to this case as for a "step-in".
<rdar://problem/16189225>
llvm-svn: 214946
|
| |
|
|
| |
llvm-svn: 214837
|
| |
|
|
| |
llvm-svn: 214836
|
| |
|
|
|
|
|
|
| |
DidAttach) the architecture of the binary you attached to.
<rdar://problem/17891396>
llvm-svn: 214603
|
| |
|
|
| |
llvm-svn: 214319
|
| |
|
|
|
|
|
|
| |
Also fixed the host 32 and 64 bit arch to return "x86_64-apple-macosx" again instead of "x86_64-apple-" (unspecified OS) after recent changes.
<rdar://problem/17845078>
llvm-svn: 214223
|
| |
|
|
|
|
|
|
|
|
|
| |
See the following llvm change for details:
r213743 | tnorthover | 2014-07-23 05:32:47 -0700 (Wed, 23 Jul 2014) | 9 lines
AArch64: remove arm64 triple enumerator.
This change fixes build breaks on Linux and MacOSX lldb.
llvm-svn: 213755
|
| |
|
|
|
|
|
|
|
| |
GCC emits a warning:
warning: enumeral and non-enumeral type in conditional expression [enabled by default]
which does not seem to have a flag to control it. Simply add an explicit cast
for the boolean value.
llvm-svn: 213715
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change enables lldb-platform for Linux. In addition, it does the following:
* fixes Host::GetLLDBPath() to work on Linux/*BSD for ePathTypeSupportExecutableDir-relative paths.
* adds more logging and comments around lldb-platform startup and remote lldb-platform usage.
* refactors lldb-platform remote-* support for Darwin and Linux into PlatformPOSIX. This, in theory, is the bulk of what is needed for *BSD to make remote connections to lldb-platform as well (although I haven't tested that yet). FreeBSD can make similar changes to their Platform* as was made here for PlatformLinux to pick up the rest of the bits.
* teaches GDBRemoteCommunication to use lldb-gdbserver for non-Apple hosts.
llvm-svn: 213707
|
| |
|
|
| |
llvm-svn: 213566
|
| |
|
|
|
|
|
|
| |
result variable and use in in "Process::LoadImage" so that,
for instance, "process load" doesn't increment the return
variable number.
llvm-svn: 213440
|
| |
|
|
|
|
|
|
| |
collect
the error if there is one.
llvm-svn: 213436
|
| |
|
|
| |
llvm-svn: 213314
|
| |
|
|
|
|
|
|
| |
and report
that in the returned Error.
llvm-svn: 213294
|
| |
|
|
|
|
|
|
|
|
| |
The problem was that we have an IOHandler thread that services the IOHandler stack. The command interepter is on the top of the stack and it receives a "expression ..." command, and it calls the IOHandlerIsComplete() callback in the command interpereter delegate which runs an expression. This causes the IOHandlerProcessSTDIO to be pushed, but since we are running the code from the IOHandler thread, it won't get run. When CTRL+C is pressed, we do deliver the interrupt to the IOHandlerProcessSTDIO::Interrupt() function, but it was always writing 'i' to the interrupt pipe, even if we weren't actively reading from the debugger input and the pipes. This fix works around the issue by directly issuing the async interrupt to the process if the process is running.
A longer term more correct fix would to be run the IOHandler thread and have it just do the determination of the input and when complete input is received, run the code that handles that input on another thread and syncronize with that other thread to detect when more input is desired. That change is too big to make right now, so this fix will tide us over until we can get there.
<rdar://problem/16556228>
llvm-svn: 213196
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This value gets set to a max uint32_t value when there is no known limit; otherwise,
it is set to a value appropriate for the platform. For the moment, only
Linux, FreeBSD and NetBSD set it to 16. All other platforms set it to
the max uint32_t value.
Modifies the Process private state thread names to fit within a 16-character limit
when the max thread name length is <= 16. These guarantee that the thread names
can be distinguished within the first 16 characters. Prior to this change, those
threads had names in the final dotted name segment that were not distinguishable
within the first 16 characters.
llvm-svn: 213183
|
| |
|
|
|
|
| |
<rdar://problem/17540766>
llvm-svn: 213007
|
| |
|
|
|
|
|
|
|
|
|
| |
Fixes include:
- Don't say that "<arch>-apple-ios" is compatible with "<arch>-apple-macosx"
- Fixed DynamicLoaderMacOSXDYLD so specify an architecture that was converted solely from a cputype and subtype, just specify the file + UUID.
- Fixed PlatformiOSSimulator::GetSupportedArchitectureAtIndex() so it returns the correct archs
- Fixed SymbolFileDWARFDebugMap to load .o files correctly by just specifying the architecture without the vendor and OS now that "<arch>-apple-ios" is not compatible with "<arch>-apple-macosx" so we can load .o files correctly for DWARF with debug map
- Fixed the coded in TargetList::CreateTarget() so it does the right thing with an underspecified triple where just the arch is specified.
llvm-svn: 212783
|
| |
|
|
|
|
|
| |
This reverts commit ec7c94f8e6860968d384b578e5564a9c55c80b4a and
re-enables OptionValidators.
llvm-svn: 212627
|
| |
|
|
|
|
|
|
|
| |
operations. Only
step-inst and step-inst are currently supported, the rest just warn that they are not supported
if you try to provide a count.
llvm-svn: 212559
|
| |
|
|
| |
llvm-svn: 212553
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverses out the options validators changes. We'll get these
back in once the changes to the output can be resolved.
Restores broken tests on FreeBSD, Linux, MacOSX.
Changes reverted: r212500, r212317, r212290.
llvm-svn: 212543
|
| |
|
|
|
|
|
| |
when you continue to finish off the function call, the expression result
will be included as part of the thread stop info.
llvm-svn: 212506
|
| |
|
|
|
|
|
|
| |
See http://llvm.org/bugs/show_bug.cgi?id=20149 for details.
Change by Randy Smith.
llvm-svn: 212485
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose of the OptionValidator is to determine, based on some
arbitrary set of conditions, whether or not a command option is
valid for a given debugger state. An example of this might be
to selectively disable or enable certain command options that
don't apply to a particular platform.
This patch contains no functional change, and does not actually
make use of an OptionValidator for any purpose yet. A follow-up
patch will begin to add the logic and users of OptionValidator.
Reviewed by: Greg Clayton, Jim Ingham
Differential Revision: http://reviews.llvm.org/D4369
llvm-svn: 212290
|
| |
|
|
| |
llvm-svn: 212246
|
| |
|
|
|
|
|
|
|
|
|
| |
Windows does support pipes, but they do so in a slightly different way. Added a Host layer which abstracts the use of pipes into a new Pipe class that everyone can use.
Windows benefits include:
- Being able to interrupt running processes when IO is directly hooked up
- being able to interrupt long running python scripts
- being able to interrupt anything based on ConnectionFileDescriptor
llvm-svn: 212220
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
off_t is a type which is used for file offsets. Even more
specifically, it is only used by a limited number of C APIs that
deal with files. Any usage of off_t where the variable is not
intended to be used with one of these APIs is a bug, by definition.
This patch corrects some easy mis-uses of off_t, generally by
converting them to lldb::offset_t, but sometimes by using other
types such as size_t, when appropriate.
The use of off_t to represent these offsets has worked fine in
practice on linux-y platforms, since we used _FILE_OFFSET_64 to
guarantee that off_t was a uint64. On Windows, however,
_FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit.
So the usage of off_t on Windows actually leads to legitimate bugs.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D4358
llvm-svn: 212192
|
| |
|
|
| |
llvm-svn: 212172
|