| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
Process::Launch try to catch a stop signal after launching a process. If
it is unsuccessful it destroy the process but previously still reported
that the process launched successfully. This behavior caused a
deadlock. With thic change the process launch error reported correctly.
Differential revision: http://reviews.llvm.org/D7784
llvm-svn: 230212
|
|
|
|
|
|
| |
This should not bring any feature change, except changing names of things here and there
llvm-svn: 230077
|
|
|
|
|
|
| |
SBTarget::LoadCore() by hijacking the public event queue so we can ensure that the event gets consumed and the public state of the process (StateType SBProcess::GetState()) returns eStateStopped.
llvm-svn: 230066
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add Host::GlobArguments() to perform local-globbing
I implemented this on OSX and Windows in terms of argdumper (Windows implementation is essentially the same as the OSX version + a change in binary name and some string magic)
Other platforms did not specifically chime in, so I left it unimplemented for them for the time being. Please feel free to fill in the blanks
- Add Platform::GlobArguments() to support remote-globbing
For now, no feature change here - but now we have infrastructure to help GDBRemote targets to support globbing - and patches to that effect will follow
No visible feature change
llvm-svn: 230065
|
|
|
|
|
|
|
|
| |
be handling the eStateStopped event we post to the private state thread causing us to return from SBTarget::LoadCore() before the process is ready to have API calls used on it.
This fixes a crasher that could happen when loading core files from scripts.
llvm-svn: 230060
|
|
|
|
|
|
|
|
|
|
|
|
| |
When launching argdumper, there are a few problems with the
current logic. First, on Windows, the file is called
argdumper.exe, not argdumper. Second, Windows paths have
backslashes in them, and JSON treats <backslash><char> as an
escape sequence. To fix the second problem, on Windows we
convert backslashes to forward slashes, since backslash isn't
a valid filename character anyway this shouldn't be a problem.
llvm-svn: 229784
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This does not fix any outstanding issue that I know of, but there is no reason these files should
_not_ have CloseOnExec.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7694
llvm-svn: 229506
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
changing it was in r219544 - after living on that for a few
months, I wanted to take another crack at this.
The disassembly-format setting still exists and the old format
can be user specified with a setting like
${current-pc-arrow}${addr-file-or-load}{ <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>}:
This patch was discussed in http://reviews.llvm.org/D7578
<rdar://problem/19726421>
llvm-svn: 229186
|
|
|
|
|
|
| |
Arg0ValueChangedCallback isn't twitching when Arg0 was updated, therefore target was launched with empty 1st argument or without it at all. In this patch I update Arg0 by hand.
llvm-svn: 229125
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds -exec-arguments command for lldb-mi. -exec-arguments command allows to specify arguments for executable file in MI mode. Also it contains tests for that command.
Btw, new added files was formatted by clang-format.
Reviewers: abidh, zturner, clayborg
Reviewed By: clayborg
Subscribers: zturner, emaste, clayborg, jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D6965
llvm-svn: 229110
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Platform holds a smart pointer to each platform object created in a
static variable what cause the platform destructors called only on
program exit when other static variables are not availables. With this
change the destructors are called on lldb_private::Terminate()
+ Fix DebuggerRefCount handling in ScriptInterpreterPython
Differential Revision: http://reviews.llvm.org/D7590
llvm-svn: 228944
|
|
|
|
|
|
|
|
|
|
| |
getting byte sizes from types.
There was a test in the test suite that was triggering the backtrace logging output that requested that the client pass an execution context. Sometimes we need the process for Objective C types because our static notion of the type might not align with the reality when being run in a live runtime.
Switched from an "ExecutionContext *" to an "ExecutionContextScope *" for greater ease of use.
llvm-svn: 228892
|
|
|
|
|
|
| |
This patch fixes r228417. It's required because eStateCrushed case wasn't investigated.
llvm-svn: 228824
|
|
|
|
|
|
|
|
|
|
|
|
| |
A runtime support value is a ValueObject whose only purpose is to support some language runtime's operation, but it does not directly provide any user-visible benefit
As such, unless the user is working on the runtime support, it is mostly safe for them not to see such a value when debugging
It is a language runtime's job to check whether a ValueObject is a support value, and that - in conjunction with a target setting - is used by frame variable and target variable
SBFrame::GetVariables gets a new overload with yet another flag to dictate whether to return those support values to the caller - that which defaults to the setting's value
rdar://problem/15539930
llvm-svn: 228791
|
|
|
|
|
|
|
|
|
|
|
| |
previously recorded values
Because types are not reliably protected against the death of their owners, having ValueObjects lurking around like that past the useful lifetime of their owner processes is a potential source of crashes
That is - in itself - worth fixing at some point, but for this case, watchpoints holding on to old values don't offer enough value to make the larger fix worth
Fixes rdar://19788756
llvm-svn: 228777
|
|
|
|
|
|
|
|
| |
SBTarget::AttachToProcess and make it work with platform for remote attach purposes.
http://reviews.llvm.org/D7471
llvm-svn: 228757
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to forward stdin when stdio is not disabled and when we're not
redirecting stdin from a file.
renamed m_stdio_disable to m_stdin_forward and inverted value because
that's what we want to remember.
There was previously a bug that if you redirected stdin from a file,
stdout and stderr would also be redirected to /dev/null
Adds support for remote target to TestProcessIO.py
Fixes ProcessIOTestCase.test_stdin_redirection_with_dwarf for remote
Linux targets
llvm-svn: 228744
|
|
|
|
|
|
| |
globbed the command line arguments via argdumper instead of routing via /bin/sh
llvm-svn: 228658
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Processes running on a remote target can already send $O messages
to send stdout but there is no way to send stdin to a remote
inferior.
This allows processes using the API to pump stdin into a remote
inferior process.
It fixes a hang in TestProcessIO.py when running against a remote
target.
llvm-svn: 228419
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in case of remote-macosx
Summary:
This patch fixes *stopped notification for remote target when started with eLaunchFlagStopAtEntry (for example, using "process launch -s").
See explanation below:
```
Target::Launch (ProcessLaunchInfo &launch_info, Stream *stream)
{
...
if (state != eStateConnected && platform_sp && platform_sp->CanDebugProcess ())
{
...
}
else
{
...
if (m_process_sp)
error = m_process_sp->Launch (launch_info);
}
if (error.Success())
{
if (launch_info.GetFlags().Test(eLaunchFlagStopAtEntry) == false)
{
....
}
-- missing event if eLaunchFlagStopAtEntry is set --
m_process_sp->RestoreProcessEvents ();
}
...
return error
```
Also this patch contains tests and you can check how it works.
Reviewers: zturner, clayborg, abidh
Reviewed By: clayborg
Subscribers: clayborg, abidh, zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D7273
llvm-svn: 228417
|
|
|
|
|
|
|
|
|
| |
This also hooks up the new C++14 language constant to be treated
the same as the other C++ language constants.
Differential Revision: http://reviews.llvm.org/D7429
llvm-svn: 228386
|
|
|
|
|
|
|
|
| |
Integrate this change into test framework in order to spawn processes on a remote target.
http://reviews.llvm.org/D7263
llvm-svn: 228230
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
class.
Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing.
The new code improves on this with the following features:
1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry.
2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format
3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it.
4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly
5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings
6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features.
7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries.
These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more).
llvm-svn: 228207
|
|
|
|
| |
llvm-svn: 228171
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Both LLDB and LLGS are leaking file descriptors into the debugged process. This plugs the leak by
closing the unneeded descriptors. In one case I use O_CLOEXEC, which I hope is supported on
relevant platforms. I also added a regression test and plugged a fd leak in dosep.py.
Reviewers: vharron, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7372
llvm-svn: 228130
|
|
|
|
| |
llvm-svn: 227929
|
|
|
|
|
|
|
|
| |
protect with modifying member variables. This mutex is designed to be used for simple modifications, so the lock should be taken, modify the member variable and released. We need to make sure this isn't used with any code that cause code to rely or reenter on another thread.
Partial fix for: <rdar://problem/19575304>
llvm-svn: 227855
|
|
|
|
|
|
|
|
|
|
| |
./dotest.py -A x86_64 -C clang -v -t -f TestImageListMultiArchitecture.test_image_list_shows_multiple_architectures
The problem was that if the platform wasn't compatible with the current file in the "target create" command, it wasn't finding a platform that was like it used to.
Also, the currently selected platform was being used upload the file _before_ the target was created which was incorrect as "target create a.out" might switch platforms if its architecture doesn't match, so I moved the uploading to happen after the target was created so we use the right platform (the one in the target, not the selected one).
llvm-svn: 227380
|
|
|
|
|
|
|
|
| |
and even if platform options are specified when doing a "target create" they would get ignored if a platform was already selected.
The change was made so we could re-use a platform if one was already created instead of creating a new one, but it would fail in the above case. To fix this, if we have a selected platform, we verify that the platform matches the current platform before we try to re-use it. We do this by asking the OptionGroupPlatform if the platform matches. If so, it returns true and we don't create a new platform, else we do.
llvm-svn: 227288
|
|
|
|
| |
llvm-svn: 227283
|
|
|
|
|
|
|
|
| |
Namely, this commit provides an actual implementation of how to retrieve the byte size in a sane way for an ObjC class, by scanning ivar offsets and byte sizes, figuring out the farthest-from-base ivar, and adding its byte size to that
Still NFC
llvm-svn: 227277
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes TestRegisters on Linux with LLGS
Introduce GetUserRegisterCount on RegisterInfoInterface to distinguish
lldb internal registers (e.g.: DR0-DR7) during register counting.
Update GDBRemoteCommunicationServer to skip lldb internal registers on
read/write register and on discover register.
Submitted for Tamas Berghammer
llvm-svn: 226959
|
|
|
|
|
|
| |
iOS and the simulator since llvm/clang will assert and kill LLDB.
llvm-svn: 226846
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make sure the selected platform is always used
Make sure that the host uses the connect://hostname to connect to both
the lldb-platform and the lldb-gdbserver rather than what the platform
reports as the hostname of the lldb-gdbserver
Make sure that lldb-platform uses the IP address on it's connection
back to the host instead of the hostname that the host sends to it
when launching lldb-gdbserver with the remote host information
Tested on OSX and Linux
llvm-svn: 226712
|
|
|
|
|
|
|
|
|
|
| |
specify compile and execute flags for regular expressions. Also enable better regular expressions if they are available by check if the REG_ENHANCED is available and using it if it is.
Since REG_ENHANCED is available on MacOSX, this allow the use of \d (digits) \b (word boundaries) and much more without affecting other systems.
<rdar://problem/12082562>
llvm-svn: 226704
|
|
|
|
|
|
|
|
|
|
| |
CommandInterpreter's execution context AFTER the process had started running
and before it initially stopped. Also fixed one test case that was implicitly
using this (and an abuse of the async mode) to accidentally succeed.
<rdar://problem/16814726>
llvm-svn: 226528
|
|
|
|
|
|
|
|
|
|
| |
The refactor was motivated by some comments that Greg made
http://reviews.llvm.org/D6918
and also to break a dependency cascade that caused functions linking
in string->int conversion functions to pull in most of lldb
llvm-svn: 226199
|
|
|
|
|
|
|
|
|
|
| |
the hit count is not updated.
Also, keep the hit count for the breakpoint in the breakpoint. We were
using just the sum of the location's hit counts, but that was wrong since if a shared library is
unloaded, and the location goes away, the breakpoint hit count should not suddenly drop
by the number of hits there were on that location.
llvm-svn: 226074
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does.
This is currently controlled by a setting:
(lldb) settings set target.process.python-os-plugin-path <path>
Or clearing it with:
(lldb) settings clear target.process.python-os-plugin-path
The process will now reload the OperatingSystem plug-in.
This was implemented by:
- adding the ability to set a notify callback for when an option value is changed
- added the ability for the process plug-in to load the operating system plug-in on the fly
- fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits
- adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user
- fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded
llvm-svn: 225831
|
|
|
|
|
|
|
|
|
|
|
|
| |
that we can turn them on by default
Change the default of prefer-dynamic-value to eDynamicDontRunTarget (i.e. enable dynamic values, but do not run code to do so)
Of course, disable this for the test suite, since testing no-dynamic-values is actually valuable
Fixes rdar://17363061
llvm-svn: 225486
|
|
|
|
|
|
|
|
| |
they would always get a non-NULL string back.
<rdar://problem/19298575>
llvm-svn: 224602
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes a number of improvements to the Pipe interface.
1) An interface (PipeBase) is provided which exposes pure virtual
methods for any implementation of Pipe to override. While not
strictly necessary, this helps catch errors where the interfaces
are out of sync.
2) All methods return lldb_private::Error instead of returning bool
or void. This allows richer error information to be propagated
up to LLDB.
3) A new ReadWithTimeout() method is exposed in the base class and
implemented on Windows.
4) Support for both named and anonymous pipes is exposed through the
base interface and implemented on Windows. For creating a new
pipe, both named and anonymous pipes are supported, and for
opening an existing pipe, only named pipes are supported.
New methods described in points #3 and #4 are stubbed out on posix,
but fully implemented on Windows. These should be implemented by
someone on the linux / mac / bsd side.
Reviewed by: Greg Clayton, Oleksiy Vyalov
Differential Revision: http://reviews.llvm.org/D6686
llvm-svn: 224442
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If a stream contains an empty string, no need to append it to the output
(otherwise we end up with a blank line). Also, no need to print a status
message when the state changes to connected, as this string brings no
information -- "Process 0" does not mean anything to the user, and the
process being connected has no meaning either.
Test Plan:
Connect to a remote linux platform mode daemon with `platform select
remote-linux` followed by `platform connect ...`, create a target and
run it, observe the output. Also, run the full test suite (dosep.py).
Before:
(lldb) [...] connect, etc.
(lldb) r
Process 0 connected
Process 5635 launched: '/Users/sas/Source/test' (x86_64)
Process 5635 stopped
After:
(lldb) [...] connect, etc.
(lldb) r
Process 5635 launched: '/Users/sas/Source/test' (x86_64)
Process 5635 stopped
Reviewers: tfiala, vharron, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6593
llvm-svn: 224188
|
|
|
|
| |
llvm-svn: 223973
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true.
When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction.
The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match.
To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed.
This patch does the following:
1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb
2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute
3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb
4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below)
This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added.
<rdar://problem/19145455>
llvm-svn: 223851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a resubmit of r223548, which was reverted due to breaking
tests on Linux and Mac.
This resubmit fixes the reason for the revert by adding back some
accidentally removed code which appends -c to the command line
when running /bin/sh.
This resubmit also differs from the original patch in that it sets
the architecture on the ProcessLaunchInfo. A follow-up patch will
refactor this to separate the logic for different platforms.
Differential Revision: http://reviews.llvm.org/D6553
Reviewed By: Greg Clayton
llvm-svn: 223695
|
|
|
|
| |
llvm-svn: 223568
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in the "dummy-target". The dummy target breakpoints prime all future
targets. Breakpoints set before any target is created (e.g. breakpoints
in ~/.lldbinit) automatically get set in the dummy target. You can also
list, add & delete breakpoints from the dummy target using the "-D" flag,
which is supported by most of the breakpoint commands.
This removes a long-standing wart in lldb...
<rdar://problem/10881487>
llvm-svn: 223565
|
|
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D6553
Reviewed By: Greg Clayton
llvm-svn: 223548
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
support to LLDB. It includes the following:
- Changed DeclVendor to TypeVendor.
- Made the ObjCLanguageRuntime provide a DeclVendor
rather than a TypeVendor.
- Changed the consumers of TypeVendors to use
DeclVendors instead.
- Provided a few convenience functions on
ClangASTContext to make that easier.
llvm-svn: 223433
|