Add some if/then to avoid calling a function to get dynamic/synthetic types if we know we aren't going to need to call it.
Avoid calling a function that returns a shared pointer twice: once for testing it and once for assigning it (even though that shared pointer is cached inside the value object), it just makes the code a bit clearer.
llvm-svn: 240299
For some communication channels, sending large packets can be very
slow. In those cases, it may be faster to compress the contents of
the packet on the target device and decompress it on the debug host
system. For instance, communicating with a device using something
like Bluetooth may be an environment where this tradeoff is a good one.
This patch adds a new field to the response to the "qSupported" packet
(which returns a "qXfer:features:" response) -- SupportedCompressions
and DefaultCompressionMinSize. These tell you what the remote
stub can support.
lldb, if it wants to enable compression and can handle one of those
algorithms, it can send a QEnableCompression packet specifying the
algorithm and optionally the minimum packet size to use compression
on. lldb may have better knowledge about the best tradeoff for
a given communication channel.
I added support to debugserver an lldb to use the zlib APIs
(if -DHAVE_LIBZ=1 is in CFLAGS and -lz is in LDFLAGS) and the
libcompression APIs on Mac OS X 10.11 and later
(if -DHAVE_LIBCOMPRESSION=1). libz "zlib-deflate" compression.
libcompression can support deflate, lz4, lzma, and a proprietary
lzfse algorithm. libcompression has been hand-tuned for Apple
hardware so it should be preferred if available.
debugserver currently only adds the SupportedCompressions when
it is being run on an Apple watch (TARGET_OS_WATCH). Comment
that #if out from RNBRemote.cpp if you want to enable it to
see how it works. I haven't tested this on a native system
configuration but surely it will be slower to compress & decompress
the packets in a same-system debug session.
I haven't had a chance to add support for this to
GDBRemoteCommunciationServer.cpp yet.
<rdar://problem/21090180>
llvm-svn: 240066
Patch by Jaydeep Patil
SUMMARY:
1. Added emulation of MIPS64 floating-point branch instructions
2. Updated GetRegisterInfo to recognize floating-point registers
3. Provided CPU information while creating createMCSubtargetInfo in disassembler
4. Bug fix in emulation of JIC and JIALC
5. Correct identification of breakpoint when set in a delay slot of a branch instruction
Reviewers: clayborg
Subscribers: bhushan, mohit.bhakkad, sagar, nitesh.jain, lldb-commits.
Differential Revision: http://reviews.llvm.org/D10355
llvm-svn: 239996
Summary:
* Fix enum LanguageType values so that they can be used as indexes
into array language_names and g_languages as assumed by
LanguageRuntime::GetNameForLanguageType,
Language::SetLanguageFromCString and Language::AsCString.
* Add DWARFCompileUnit::LanguageTypeFromDWARF to convert from DWARF
DW_LANG_* values to enum LanguageType values.
Reviewed By: clayborg, abidh
Differential Revision: http://reviews.llvm.org/D10484
llvm-svn: 239963
Summary:
Memory reads using the ptrace API need to be executed on a designated thread
and in 4-byte increments. The process_vm_read syscall has no such requirements
and it is about 50 times faster. This patch makes lldb-server use the faster
API if the target kernel supports it. Kernel support for this feature is
determined at runtime. Using process_vm_writev in the same manner is more
complicated since this syscall (unlike ptrace) respects page protection settings
and so it cannot be used to set a breakpoint, since code pages are typically
read-only. However, memory writes are not currently a performance bottleneck as
they happen much more rarely.
Test Plan: all tests continue to pass
Reviewers: ovyalov, vharron
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D10488
llvm-svn: 239924
Because vector types use their formats in special ways (i.e. children get generated based on them), this change by itself would cause a regression in printing vector types with some custom formats
Work around that issue by special casing vector types out of this format-passdown mode. I believe there is a more general feature to be designed in this space, but until I see more cases of interest, I am going to leave this as a special case
Fixes rdar://20810062
llvm-svn: 239873
In order to support asynchronous notifications for non-stop mode this patch adds a packet read thread. This is done by implementing AppendBytesToCache() from the communications class, which continually reads packets into a packet queue. To initialize this thread StartReadThread() must be called by the client, so since llgs and platform tools use the GBDRemoteCommunicatos code they must also call this function as well as ProcessGDBRemote.
When the read thread detects an async notify packet it broadcasts this event, where the matching listener will be added in the next non-stop patch.
Packets are now accessed by calling ReadPacket() which pops a packet from the queue, instead of using WaitForPacketWithTimeoutMicroSecondsNoLock()
Reviewers: vharron, clayborg
Subscribers: lldb-commits, labath, ted, domipheus, deepak2427
Differential Revision: http://reviews.llvm.org/D10085
llvm-svn: 239824
There are other characters we could optimize for (any non-letter pretty much), but keyword.iskeyword() will handle them, whereas quotes do have the potential to confuse us, so they actually need custom handling
Fixes rdar://problem/21022787
llvm-svn: 239779
The problem is for lldb_private::Type instances that have encoding types (pointer/reference/const/volatile/restrict/typedef to type with user ID 0x123). If they started out with m_flags.clang_type_resolve_state being set to eResolveStateUnresolved (0), then when we would call Type::ResolveClangType(eResolveStateForward) we would complete the full type due to logic errors in the code.
We now only complete the type if clang_type_resolve_state is eResolveStateLayout or eResolveStateFull and we correctly upgrade the type's current completion state to eResolveStateForward after we make a forward delcaration to the pointer/reference/const/volatile/restrict/typedef type instead of leaving it set to eResolveStateUnresolved.
llvm-svn: 239752
Summary:
`IsRelativeToCurrentWorkingDirectory` was misleading, because relative paths
are sometimes appended to other directories, not just the cwd. Plus, the new
name is shorter. Also added `IsAbsolute` for completeness.
Reviewers: clayborg, ovyalov
Reviewed By: ovyalov
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D10262
llvm-svn: 239419
Summary:
Update DYLDRendezvous and SOEntry to use FileSpecs instead of storing paths as
strings, which caused incorrect comparison results due to denormalization.
Reviewers: clayborg, vharron, ovyalov
Reviewed By: ovyalov
Subscribers: jwolfe, emaste, tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D10267
llvm-svn: 239195
Setting the OSType in the ArchSpec triple is needed to correctly setup
up the register context plugin. ArchSpec::SetArchitecture, for Mach-O
only, sets the OSType. For ELF it was left to the ObjectFileELF to fill
in the missing OSType.
This change moves the ObjectFileELF logic into ArchSpec.
A new optional 'os' parameter has been added to SetArchitecture.
For ELF, this value is the from the ELF header.e_ident[EI_OSABI].
The default value is 0 or ELFOSABI_NONE.
The real work of determining the OSType was done by the ObjectFileELF
helper function GetOsFromOSABI. This logic has been moved
SetArchitecture.
GetOsFromOSABI has been commented as being deprectated. It is left in
to support asserts.
For ELF the vendor value returned from SetArchitecture should be
UnknownVendor. An unneeded resetting in ObjectFileELF has been removed
and replaced with an assert.
This fixes a problem reading a core file on FreeBSD/ARM because the spec
triple was arm-unknown-unknown.
Patch by Tom Rix.
Differential Revision: http://reviews.llvm.org/D9292
llvm-svn: 239148
This was of course overridable by using DumpValueObjectOptions, but the default should be saner and the previous behavior made for a few fun investigations....
rdar://problem/21065149
llvm-svn: 238961
(lldb) settings set thread-format "abc"
(lldb) settings set thread-format 'abc'
(lldb) settings set thread-format abc
We strip the quotes before processing the format string and return an "error: mismatched quotes" if mismatched quotes are given.
<rdar://problem/21210789>
llvm-svn: 238896
The problem was the mutex was only protecting the setting of m_exit_string and m_exit_string, but this function relies on the m_private_state being set to eStateExited in order to prevent more than 1 client setting the exit status. We want to only allow the first caller to succeed.
On MacOSX we have a thread that reaps the process we are debugging, and we also have a thread that monitors the debugserver process. When a process exists, the ProcessGDBRemote::AsyncThread() would set the exit status to the correct value and then another thread would reap the debugserver process and they would often both end up in Process::SetExitStatus() at the same time. With the mutex at the top we allow all variables to be set and the m_private_state to be set to eStateExited _before_ the other thread (debugserver reaped) can try to set th exist status to -1 and "lost connection to debugserver" being set as the exit status.
This was probably an issue for lldb-server as well and could very well cleanup some tests that might have been expecting a specific exit status from the process being debugged.
llvm-svn: 238794
Base framework for inspecting RenderScript runtime details and helpers for various runtime actions on x86 and arm targets.
Differential Revision: http://reviews.llvm.org/D10151
llvm-svn: 238768
When the current address is pointing 1 (unit) over the end of a
section the we have to do a section lookup after making the adjusment
of the current address.
Differential revision: http://reviews.llvm.org/D10124
llvm-svn: 238737
Summary:
This should solve the issue of sending denormalized paths over gdb-remote
if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the
server handle any denormalization.
Reviewers: ovyalov, zturner, vharron, clayborg
Reviewed By: clayborg
Subscribers: tberghammer, emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D9728
llvm-svn: 238604
Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore, all includes of it should be localized to
the python library which will live under source/bindings/API/Python
after a future patch.
None of the files that were including this header actually depended
on it anyway, so it was just a dead include in every single instance.
llvm-svn: 238581
Summary:
Previously, we reported inferior receiving SIGSEGV (or SIGILL, SIGFPE, SIGBUS) as an "exception"
to LLDB, presumably to match OSX behaviour. Beside the fact that we were basically lying to the
user, this was also causing problems with inferiors which handle SIGSEGV by themselves, since
LLDB was unable to reinject this signal back into the inferior.
This commit changes LLGS to report SIGSEGV as a signal. This has necessitated some changes in the
test-suite, which had previously used eStopReasonException to locate threads that crashed. Now it
uses platform-specific logic, which in the case of linux searches for eStopReasonSignaled with
signal=SIGSEGV.
I have also added the ability to set the description of StopInfoUnixSignal using the description
field of the gdb-remote packet. The linux stub uses this to display additional information about
the segfault (invalid address, address access protected, etc.).
Test Plan: All tests pass on linux and osx.
Reviewers: ovyalov, clayborg, emaste
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D10057
llvm-svn: 238549
qEcho:%s
where '%s' is any valid string. The response to this packet is the exact packet itself with no changes, just reply with what you received!
This will help us to recover from packets timing out much more gracefully. Currently if a packet times out, LLDB quickly will hose up the debug session. For example, if we send a "abc" packet and we expect "ABC" back in response, but the "abc" command takes longer than the current timeout value this will happen:
--> "abc"
<-- <<<error: timeout>>>
Now we want to send "def" and get "DEF" back:
--> "def"
<-- "ABC"
We got the wrong response for the "def" packet because we didn't sync up with the server to clear any current responses from previously issues commands.
The fix is to modify GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock() so that when it gets a timeout, it syncs itself up with the client by sending a "qEcho:%u" where %u is an increasing integer, one for each time we timeout. We then wait for 3 timeout periods to sync back up. So the above "abc" session would look like:
--> "abc"
<-- <<<error: timeout>>> 1 second
--> "qEcho:1"
<-- <<<error: timeout>>> 1 second
<-- <<<error: timeout>>> 1 second
<-- "abc"
<-- "qEcho:1"
The first timeout is from trying to get the response, then we know we timed out and we send the "qEcho:1" packet and wait for 3 timeout periods to get back in sync knowing that we might actually get the response for the "abc" packet in the mean time...
In this case we would actually succeed in getting the response for "abc". But lets say the remote GDB server is deadlocked and will never response, it would look like:
--> "abc"
<-- <<<error: timeout>>> 1 second
--> "qEcho:1"
<-- <<<error: timeout>>> 1 second
<-- <<<error: timeout>>> 1 second
<-- <<<error: timeout>>> 1 second
We then disconnect and say we lost connection.
We might also have a bad GDB server that just dropped the "abc" packet on the floor. We can still recover in this case and it would look like:
--> "abc"
<-- <<<error: timeout>>> 1 second
--> "qEcho:1"
<-- "qEcho:1"
Then we know our remote GDB server is still alive and well, and it just dropped the "abc" response on the floor and we can continue to debug.
<rdar://problem/21082939>
llvm-svn: 238530
it an extern "C" function instead of a C++ function
so that Clang doesn't emit a mangled function reference.
Also removed the hack in ClangExpressionDeclMap that
works around this.
llvm-svn: 238476
Summary:
LLDB on Windows should now be able to demangle Linux/Android symbols.
Also updated CxaDemangle.cpp to be compatible with MSVC.
Depends on D9949, D9954, D10048.
Reviewers: zturner, emaste, clayborg
Reviewed By: clayborg
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D10040
llvm-svn: 238460
Summary: In preparation for some changes to make this compatible with MSVC.
Reviewers: emaste, zturner, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9949
llvm-svn: 238459
Summary:
IOHandlerProcessSTDIO::Run() was opening the pipe for interrupt requests lazily. This was racing
with another thread executing IOHandlerProcessSTDIO::Cancel() simultaneously. I fix this by
opening the pipe in the object constructor. The pipe will be automatically closed when the object
is destroyed.
Test Plan: Tests pass on linux.
Reviewers: clayborg, ribrdb
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10060
llvm-svn: 238423
Patch by Tom Rix, with additional changes to sync whitespace/style with
PlatformLinux.cpp.
It is currently disabled pending kernel support.
Differential Revision: http://reviews.llvm.org/D9170
llvm-svn: 238420
Summary:
Previously, we wait()ed for events from the inferiors process group. This is resulted in a
failure if the inferior changed its process group in the middle of execution. To avoid this, I
pass -1 to the wait() call. The flag __WNOTHREAD makes sure we don't actually wait for events
from any process, but only the processes(threads) which are our children (or traced by us). Since
this happens on the monitor thread, which is dedicated to monitoring a single inferior, we will
be getting events only from this inferior.
Test Plan: All tests pass on linux. I have added a test to check the new functionality.
Reviewers: chaoren, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10061
llvm-svn: 238405
lldb::addr_t SBFrame::GetCFA();
This gets the CFA (call frame address) of the frame so it allows us to take an address that is on the stack and figure out which thread it comes from.
Also modified the heap.py module to be able to find out which variable in a frame's stack frame contains an address. This way when ptr_refs finds a match on the stack, it get then report which variable contains the pointer.
llvm-svn: 238393
This was the original cause of the file descriptor leaks that would cause the test suite to die after running a few hundred processes since no process would ever get destroyed and the communication channel in ProcessGDBRemote and the ProcessIOHandler would never close their pipes.
This process leak was previously worked around by closing the pipes when the communication channel was disconnected.
This was found by using "ptr_refs" from the heap.py in the lldb.macosx.heap module. It was able to find all strong references to the Process and helped me to figure out who was holding this extra reference.
llvm-svn: 238392
expr_options = lldb.SBExpressionOptions()
expr_options.SetPrefix('''
struct Foo {
int a;
int b;
int c;
}
'''
expr_result = frame.EvaluateExpression ("Foo foo = { 1, 2, 3}; foo", expr_options)
This fixed a current issue with ptr_refs, cstr_refs and malloc_info so that they can work. If expressions define their own types and then return expression results that use those types, those types get copied into the target's AST context so they persist and the expression results can be still printed and used in future expressions. Code was added to the expression parser to copy the context in which types are defined if they are used as the expression results. So in the case of types defined by expressions, they get defined in a lldb_expr function and that function and _all_ of its statements get copied. Many types of statements are not supported in this copy (array subscript, lambdas, etc) so this causes expressions to fail as they can't copy the result types. To work around this issue I have added code that allows expressions to specify an expression specific prefix. Then when you evaluate the expression you can pass the "expr_options" and have types that can be correctly copied out into the target. I added this as a way to work around an issue, but I also think it is nice to be allowed to specify an expression prefix that can be reused by many expressions, so this feature is very useful.
<rdar://problem/21130675>
llvm-svn: 238365
In ProcessGDBRemote we currently have a single packet, m_last_stop_packet, used to set the thread stop info.
However in non-stop mode we can receive several stop reply packets in a sequence for different threads. As a result we need to use a container to hold them before they are processed.
This patch also changes the return type of CheckPacket() so we can detect async notification packets.
Reviewers: clayborg
Subscribers: labath, ted, deepak2427, lldb-commits
Differential Revision: http://reviews.llvm.org/D9853
llvm-svn: 238323
This change also get rid of an unused Debugger instance in
GDBRemoteCommunicationServerLLGS and the command interpreter from
lldb-platform what was used only for enabling logging.
Differential revision: http://reviews.llvm.org/D9876
llvm-svn: 238319
Summary:
There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix
we have in for this is not working all the time and is introducing unnecessary delays. This
change does:
- Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being
confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to
lldb-dev.
- coordinates printing of asynchronous text with the iohandlers. This is also based on a
(different) Greg's patch, but I have added stronger synchronization to it to avoid races.
Together, these changes solve the prompt problem for me on linux (both with and without libedit).
I think they should behave similarly on Mac and FreeBSD and I think they will not make matters
worse for windows.
Test Plan: Prompt comes out alright. All tests still pass on linux.
Reviewers: clayborg, emaste, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9823
llvm-svn: 238313
A DW_TAG_subprogram entry can contain a reference to a
DW_AT_abstract_origin entry instead of duplicating the information
from it (e.g.: name) when the same function is inlined in some case
and not inlined in other cases.
This CL fixes name parsing for the case when the DW_TAG_subprogram
for the non inlined version contains just a reference to the
DW_AT_abstract_origin entry instead of the full information.
Differential revision: http://reviews.llvm.org/D10034
llvm-svn: 238307
This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags())
Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ...
Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones
llvm-svn: 238286
Using the adb push protocol is significantly faster than the current method of
sending the hex encoded file data for the remote to write to the file.
Test Plan:
Tests continue to pass - and much faster (e.g. TestSBValuePersist.py takes 10s
down from 4m51s on mac -> android)
Differential Revision: http://reviews.llvm.org/D9943
llvm-svn: 238274
We know have on API we should use for all XML within LLDB in XML.h. This API will be easy back the XML parsing by different libraries in case libxml2 doesn't work on all platforms. It also allows the only place for #ifdef ...XML... to be in XML.h and XML.cpp. The API is designed so it will still compile with or without XML support and there is a static function "bool XMLDocument::XMLEnabled()" that can be called to see if XML is currently supported. All APIs will return errors, false, or nothing when XML isn't enabled.
Converted all locations that used XML over to using the host XML implementation.
Added target.xml support to debugserver. Extended the XML register format to work for LLDB by including extra attributes and elements where needed. This allows the target.xml to replace the qRegisterInfo packets and allows us to fetch all register info in a single packet.
<rdar://problem/21090173>
llvm-svn: 238224
This change reorganize the register read/write code inside lldb-server on Linux
with moving the architecture independent code into a new class called
NativeRegisterContextLinux and all of the architecture dependent code into the
appropriate NativeRegisterContextLinux_* class. As part of it the compilation of
the architecture specific register contexts are only compiled on the specific
architecture because they can't be used in other cases.
The purpose of this change is to remove a lot of duplicated code from the different
register contexts and to remove the architecture dependent codes from the global
NativeProcessLinux class.
Differential revision: http://reviews.llvm.org/D9935
llvm-svn: 238196
If binding to port 0 is selected, the actual port is printed.
This improves the reliability of platform startup by ensuring that
a free port can be found.
TEST PLAN
./lldb-server platform --listen *:0
Listening for a connection from <port-number>...
Will appear on stdout (with other stuff potentially)
llvm-svn: 238173
The main issue was the Communication::Disconnect() was calling its Connection::Disconnect() but this wouldn't release the pipes that the ConnectionFileDescriptor was using. We also have someone that is holding a strong reference to the Process so that when you re-run, target replaces its m_process_sp, but it doesn't get destructed because someone has a strong reference to it. I need to track that down. But, even if we have a strong reference to the a process that is outstanding, we need to call Process::Finalize() to have it release as much of its resources as possible to avoid memory bloat.
Removed the ProcessGDBRemote::SetExitStatus() override and replaced it with ProcessGDBRemote::DidExit().
Now we aren't leaking file descriptors and the stand alone test suite should run much better.
llvm-svn: 238089
Summary: This enables correct handling of real time signals by lldb.
Test Plan: Added a test that verifies handling of SIGRTMIN
Reviewers: tberghammer, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9911
llvm-svn: 238009
ModuleSpecs::FindMatchingModuleSpec looks for matching filenames but when
looking for the dSYM we should only be looking for a matching architecture and
and UUID. Jason pointed out this mistake in http://reviews.llvm.org/D9174 when
this function was incorrectly converted to not be Mac specific.
Test Plan:
Running LLDB on test/lang/c/shared_lib_stripped_symbols/a.out in a debugger I've
verified LocateDSYMInVincinityOfExecutable correctly locates the matching dSYM.
Differential Revision: http://reviews.llvm.org/D9896
llvm-svn: 237907
This is neccessary for evaluating expressions with float/double return
value and for displaying float/double return values in case of a thread
step out.
Differential revision: http://reviews.llvm.org/D9907
llvm-svn: 237900
Summary:
Previously, NPL tried to reinject SIGSTOP into the inferior in an attempt to get the process to
start in the group-stop state. This was:
a) wrong (reinjection should be controlled by "process handle" lldb setting)
b) racy (it should use Resume for transparent resuming instead of RequestResume)
c) broken (llgs crashed on inferior SIGSTOP)
With this change, SIGSTOP is handled just like any other signal delivered to the inferior: we
stop all threads and report signal reception to lldb. SIGSTOP reinjection does not behave the
same way as it would outside the debugger, but simulating this is a hard problem and is not
normally necessary.
Test Plan: I have added a test which verifies we get SIGSTOP reports and we do not crash.
Reviewers: ovyalov, chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9852
llvm-svn: 237880
breakpoint only if the process it was for is still alive. We need to always remove this because
it has a pointer to the old loader, and if we ever hit it we will crash. I also put in a sanity
check in the callback function to make sure we don't invoke it if the process is wrong.
<rdar://problem/21006189>
llvm-svn: 237866
Summary: It should default to working-dir/src-filename if dst is not specified.
Reviewers: clayborg, flackr
Reviewed By: flackr
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9890
llvm-svn: 237831
Summary:
The test in TestPlatformCommand which runs "platform process list" has
been timing out for Android when running running dosep.py with
LLDB_TEST_THREADS=8. This patch increases the packet timeout to a large
value of 1min to accommodate the long time required for a response for
the qfProcessInfo packet on Android.
Test Plan: LLDB_TEST_THREADS=8 ./dosep.py on Android.
Reviewers: chaoren
Reviewed By: chaoren
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D9866
llvm-svn: 237752
It turns out, child values also need similar provisions
This patch simplifies things a bit allowing ValueObject subclasses to just declare whether they can accept an invalid context at update time, and letting the update machinery in the EvaluationPoint to the rest
Also, this lets ValueObjectChild proclaim that its parent chooses whether such blank-slate updates are possible
llvm-svn: 237714
This patch initially was committed in r237460 but later it was reverted (r237479) due to 4 new failures:
* TestExitDuringStep.py
* TestNumThreads.py
* TestThreadExit.py
* TestThreadStates.py
This patch also fixes these tests.
llvm-svn: 237566
And they also do not have a thread/frame attached to them
That makes dynamic and synthetic values attached to them impossible to update - which, among other things, makes it impossible to properly display persistent variables of types that could have such dynamic/persistent values
Fix this by making it so that a ValueObject can control its constantness (hint: dynamic and synthetic values cannot be constant) and whether it wants to let itself be updated when an invalid thread is around
llvm-svn: 237504
In http://reviews.llvm.org/D9754 I enabled the mangled symbol name lookup
workaround used to find global and anonymous namespace symbols in linux binaries
for all platforms, however we should still only check for these symbols when
processing Linux or FreeBSD binaries where they are relevant. This patch makes
this change.
Test Plan: The tests from the original revision still pass:
TestCallCPPFunction.py
TestCallStopAndContinue.py
TestExprs.py
TestExprsChar.py
TestNamespace.py
TestOverloadedFunctions.py
TestRvalueReferences.py
TestThreadExit.py
Differential Revision: http://reviews.llvm.org/D9782
llvm-svn: 237467
Summary:
This option forces to only set a source line breakpoint when there is an exact-match
This patch includes the following commits:
# Add the -m/--exact-match option in "breakpoint set" command
## Add exact_match arg in BreakpointResolverFileLine ctor
## Add m_exact_match field in BreakpointResolverFileLine
## Add exact_match arg in BreakpointResolverFileRegex ctor
## Add m_exact_match field in BreakpointResolverFileRegex
## Add exact_match arg in Target::CreateSourceRegexBreakpoint
## Add exact_match arg in Target::CreateBreakpoint
## Add -m/--exact-match option in "breakpoint set" command
# Add target.exact-match option to skip BP if source line doesn't match
## Add target.exact-match global option
## Add Target::GetExactMatch
## Refactor Target::CreateSourceRegexBreakpoint to accept LazyBool exact_match (was bool)
## Refactor Target::CreateBreakpoint to accept LazyBool exact_match (was bool)
# Add target.exact-match test in SettingsCommandTestCase
# Add BreakpointOptionsTestCase tests to test --skip-prologue/--exact-match options
# Fix a few typos in lldbutil.check_breakpoint_result func
# Rename --exact-match/m_exact_match/exact_match/GetExactMatch to --move-to-nearest-code/m_move_to_nearest_code/move_to_nearest_code/GetMoveToNearestCode
# Add exact_match field in BreakpointResolverFileLine::GetDescription and BreakpointResolverFileRegex::GetDescription, for example:
was:
```
1: file = '/Users/IliaK/p/llvm/tools/lldb/test/functionalities/breakpoint/breakpoint_command/main.c', line = 12, locations = 1, resolved = 1, hit count = 2
1.1: where = a.out`main + 20 at main.c:12, address = 0x0000000100000eb4, resolved, hit count = 2
```
now:
```
1: file = '/Users/IliaK/p/llvm/tools/lldb/test/functionalities/breakpoint/breakpoint_command/main.c', line = 12, exact_match = 0, locations = 1, resolved = 1, hit count = 2
1.1: where = a.out`main + 20 at main.c:12, address = 0x0000000100000eb4, resolved, hit count = 2
```
Test Plan:
./dotest.py -v --executable $BUILDDIR/bin/lldb functionalities/breakpoint/
./dotest.py -v --executable $BUILDDIR/bin/lldb settings/
./dotest.py -v --executable $BUILDDIR/bin/lldb tools/lldb-mi/breakpoint/
Reviewers: jingham, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits, clayborg, jingham
Differential Revision: http://reviews.llvm.org/D9273
llvm-svn: 237460
Summary:
There was an issue in NPL, where we attempted removal of temporary breakpoints (used to implement
software single stepping), while some threads of the process were running. This is a problem
since we currently always use the main thread's ID in the removal ptrace call. Therefore, if the
main thread was still running, the ptrace call would fail, and the software breakpoint would
remain, causing all kinds of problems. This change removes the breakpoints after all threads have
stopped. This fixes TestExitDuringStep on Android arm and can also potentially help in other
situations, as previously the breakpoint would not get removed if the thread stopped for another
reason.
Test Plan: TestExitDuringStep passes, other tests remain unchanged.
Reviewers: tberghammer
Subscribers: tberghammer, aemerson, lldb-commits
Differential Revision: http://reviews.llvm.org/D9792
llvm-svn: 237448
Summary:
This is the same issue as we had in D9145 for thread creation. Going through the full
ThreadDidStop/RequestResume cycle can cause a deferred notification to fire, which is not correct
when we are ignoring an event and resuming the thread. In this case it doesn't matter much since
the thread will die after that anyway, but for correctness, we should do the same thing here.
Also treating the SIGTRAP case the same way.
Test Plan: Tests continue to pass.
Reviewers: chaoren, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9696
llvm-svn: 237445
r237411 exposed the following issue: ProcessGDBRemote used the description field in the
stop-reply to set the description of the StopInfo. In the case of watchpoints, the packet
description contains the raw address that got hit, which is not exactly the information we want
to display to the user as the stop info. Therefore, I have changed the code to use the packet
description only if the StopInfo does not already have a description. This makes the behavior
equivalent to the pre-r237411 behavior as then the SetDecription call got ignored for
watchpoints.
llvm-svn: 237436
Summary:
Implementation of assembly profiler for MIPS32 using EmulateInstruction which currently scans only prologue/epilogue assembly instructions. It uses llvm::MCDisassembler to decode assembly instructions.
Reviewers: clayborg, jasonmolenda
Differential Revision: http://reviews.llvm.org/D9769
llvm-svn: 237420
Remove the m_description ivar from the StopInfoBreakpoint
and StopInfoWatchpoint subclasses of StopInfo. Also,
initialize the m_description ivar in the StopInfo ctor.
<rdar://problem/20902950>
llvm-svn: 237411
This API has been present since XP, and I think it's safe to
drop support for XP (since other things have been introduced long
ago which already don't work on XP anyway).
With this patch, we can statically bind against the exports and
not bother falling back to a CRITICAL_SECTION if we can't load
the API.
llvm-svn: 237402
Someone must have changed the behavior of FileSpec slightly
relating to whether or not there is a trailing backslash when calling
GetPath() and GetDirectory(). This caused ScriptInterpreterPython
to find the wrong values when initializing sys.path, and as a result
we couldn't find the lldb module.
This patch fixes the issue, and also adds a test to make sure that
GetDirectory() does not return a string containing a trailing slash.
llvm-svn: 237282
There were two versions of DoAttachToprocessWithId. One that takes
a pid_t, and the other which takes a pid_t and a ProcessAttachInfo.
There were no callers of the former version, and all of the
implementations of this version were simply forwarding calls to
one version or the other.
llvm-svn: 237281
Summary:
This was originally http://reviews.llvm.org/D8709 , but I didn't commit it correctly.
Since then GetSupportedArchitectureAtIndex() has been changed. That change, http://reviews.llvm.org/D9511 , breaks non-x86 linux implementations, so this change goes back to the old implementation and adds remote linux support from D8709.
D8709 summary:
The Linux Platform currently will only say the Host architecture is supported. This patch retains that behavior for the Host Platform, but adds a list of architectures for the Remote Platform.
Reviewers: clayborg, flackr
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9683
llvm-svn: 237278
all hosts.
We require a workaround to be able to locate global and anonymous namespace
functions in the dwarf symbols on linux binaries. This patch enables this code
on all platforms so that we can still find these symbols when debugging from a
different host platform.
Test Plan:
The following tests begin passing when running with a mac host to linux client:
TestCallCPPFunction.py
TestCallStopAndContinue.py
TestExprs.py
TestExprsChar.py
TestNamespace.py
TestOverloadedFunctions.py
TestRvalueReferences.py
TestThreadExit.py
Differential Revision: http://reviews.llvm.org/D9754
llvm-svn: 237270
Summary:
This patch is the beginnings of support for Non-stop mode in the remote protocol. Letting a user examine stopped threads, while other threads execute freely.
Non-stop mode is enabled using the setting target.non-stop-mode, which sends a QNonStop packet when establishing the remote connection.
Changes are also made to treat the '?' stop reply packet differently in non-stop mode, according to spec https://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop.
A setting for querying the remote for default thread on setup is also included.
Handling of '%' async notification packets will be added next.
Reviewers: clayborg
Subscribers: lldb-commits, ADodds, ted, deepak2427
Differential Revision: http://reviews.llvm.org/D9656
llvm-svn: 237239
A dummy target is used by TargetList::CreateTargetInternal to prime newly
created targets. the first time this is done it creates the dummy target. The
dummy target is created with the host platform (See
TargetList::CreateDummyTarget) which results in switching the selected platform
back to the host platform even when creating a target for a different platform.
This change avoids changing the selected platform while creating the dummy
target to prevent this side effect.
Test Plan:
./dotest.py $DOTEST_OPTS -t -p TestCreateAfterAttach.py
Tests using process attach (e.g. TestCreateAfterAttach.py, TestHelloWorld.py)
now run successfully mac -> linux.
Differential Revision: http://reviews.llvm.org/D9712
llvm-svn: 237221
Removed some unused variables, added some consts, changed some casts
to const_cast. I don't think any of these changes are very
controversial.
Differential Revision: http://reviews.llvm.org/D9674
llvm-svn: 237218
Summary:
GetCurrentDirectory() returns the number of characters copied; 0 is a failure, not a success.
Add implementation for chdir().
Reviewers: zturner
Reviewed By: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9300
llvm-svn: 237162
Updated PlatformLinux::GetSupportedArchitectureAtIndex to call the
PlatformRemoteGdbServer::GetSupportedArchitectureAtIndex if connected remotely.
This should return the correct thing for android (to fix those failing tests),
and is also working for mac to linux.
Test Plan:
./dotest.py $DOTEST_OPTS -t -p TestCallStdStringFunction.py
The above still passes when running mac->linux indicating it successfully
identified PlatformLinux as the target platform and converted the mmap options
correctly.
Differential Revision: http://reviews.llvm.org/D9672
llvm-svn: 237128
The defult implementation falls back to GetRegisterCount what
includes the debug registers also what shouldn't be displayed to
the user.
llvm-svn: 237111
Summary:
NPL::Resume attempted to handle eStateStopped as a resume action. However:
- GDBRemoteCommunicationServerLLGS (the only user of NPL) never sets this action
- it could set this action in response to a vCont:t packet, but LLDB never produces this packet
- gdb-remote protocol documentation says vCont:t packet is used only in non-stop mode, but LLDB
does not support non-stop mode
- even if LLDB supported non-stop mode, this implementation of eStateStopped does something
different from what the spec says it should (according to spec, it should stop the specified
thread, but this seems to want to stop all threads).
Given the facts above, I believe we should remove this unused and untested code, as it probably
doesn't even work and removing it makes the rest of the code noticably simpler.
Reviewers: ovyalov, chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9657
llvm-svn: 237103
Summary:
Since the former-TSC events are now processed synchronously, there is no need for to protect them
with a separate mutex - all the actions are now guarded by the big m_threads_mutex.
With the mutex gone, the following functions, no longer have any purpose and were removed:
NotifyThreadCreate: replaced by direct calls to ThreadWasCreated
NotifyThreadStop: replaced by direct calls to ThreadDidStop
NotifyThreadDeath: folded into StopTrackingThread
ResetForExec: inlined as it consisted of a single line of code
RequestThreadResume(AsNeeded): replaced by direct calls to ResumeThread
StopThreads: removed, as it was never called
Test Plan: tests continue to pass
Reviewers: ovyalov, chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9603
llvm-svn: 237101
Summary:
TargetList::CreateTargetInternal() will only select the current Platform. A previous patch always sets platform_sp to the current Platform, so a check later to see if platform_sp was not defined always failed, and the current Platform was used. This patch removes that check, so if the current Platform is not compatible with the target architecture, CreateTargetInternal() will call Platform::GetPlatformForArchitecture() to select a compatible Platform.
Vince, remote linux tests (Ubuntu -> remote Ubuntu) pass the same with and without this patch.
Reviewers: vharron, clayborg
Reviewed By: clayborg
Subscribers: jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D8749
llvm-svn: 237053
Summary: The Linux Platform shouldn't care about the Vendor field in the Triple. Currently it allows a value of "PC", or "unknown" if LLDB was built on Linux. This patch removes that check, so the Vendor field isn't touched. This will allow the Linux Platform to be created when using a Triple of *-*-Linux.
Reviewers: vharron, clayborg, sas, tberghammer
Reviewed By: clayborg, sas, tberghammer
Subscribers: tberghammer, sas, lldb-commits
Differential Revision: http://reviews.llvm.org/D8742
llvm-svn: 237052
Summary:
Hexagon is a VLIW processor. It can execute multiple instructions at once, called a packet. Breakpoints need to be alone in a packet. This patch will make sure that temporary breakpoints used for stepping are set at the start of a packet, which will put the breakpoint in a packet by itself.
Patch by Deepak Panickal of CodePlay and Ted Woodward of Qualcomm.
Reviewers: deepak2427, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9437
llvm-svn: 237047
Greg Clayton