result_formatter used inspect.getfile() to get the python file name, which returned "*.pyc" if
the bytecode file was present. This resulted in files being displayed with the wrong extension,
and more critically, would confuse the rerun logic because it would try to rerun the pyc file
(which resulted in an empty rerun list as unittest refused to run those).
Fix: use inspect.getsourcefile() instead.
I am not sure why does was not an issue before. I can only assume that some system update
tricked python into producing bytecode files more aggressively.
llvm-svn: 266192
will not exceed the bounds of their Section. This is addressing a
problem where a file had a large space between two sections that
were not used by this module - the last symbol in the text section
had an enormous size because the distance between that and the first
symbol in the data section were used to compute the size.
http://reviews.llvm.org/D19004
<rdar://problem/25227945>
llvm-svn: 266165
When run with the multiprocess test runner, the getchar() trick doesn't work, so ninja check-lldb would fail on this test, but running the test directly worked fine.
Differential Revision: http://reviews.llvm.org/D19035
llvm-svn: 266145
(lldb) b ~Foo
(lldb) b Foo::~Foo
(lldb) b Bar::Foo::~Foo
Improved out C++ breakpoint locations tests as well to cover this issue.
<rdar://problem/25577252>
llvm-svn: 266139
The result variables aren't useful, and if you have a breakpoint on a
common function you can generate a lot of these. So I changed the
code that checks the condition to set ResultVariableIsInternal in the
EvaluateExpressionOptions that we pass to the execution.
Unfortunately, the check for this variable was done in the wrong place
(the static UserExpression::Evaluate) which is not how breakpoint
conditions execute expressions (UserExpression::Execute). So I moved
the check to UserExpression::Execute (which Evaluate also calls) and made the
overridden method DoExecute.
llvm-svn: 266093
this test was unintentionally XFAILed due to a change in the behavior of the expectedFailure
decorator. Fix that. Also, mark the test as debug-info independent while I'm in there.
llvm-svn: 266072
The structure definitions are not provided, but we perform a sizeof operation of
them which causes a build failure. Include `asm/ptrace.h` to get the structure
definitions.
llvm-svn: 266042
Summary:
If we recieve a SIGCONT or SIGTSTP, while the driver is shutting down (which, sometimes, we do,
for reasons which are not completely clear to me), we would crash to due a null pointer
dereference. Guard against this situation.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18965
llvm-svn: 265958
-thread-info in lldbmi does not conform to protocol. Should end with
current thread id as described here:
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Thread-Commands.html#GDB_002fMI-Thread-Commands
When printing all threads, the current thread id should be printed
afterwards.
Example:
-thread-info
^done,threads=[
{id="2",target-id="Thread 0xb7e14b90 (LWP 21257)",
frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",
args=[]},state="running"},
{id="1",target-id="Thread 0xb7e156b0 (LWP 21254)",
frame={level="0",addr="0x0804891f",func="foo",
args=[{name="i",value="10"}],
file="/tmp/a.c",fullname="/tmp/a.c",line="158"},
state="running"}],
current-thread-id="1"
(gdb)
Patch from jacdavis@microsoft.com
Reviewers: zturner, chuckr
Differential Revision: http://reviews.llvm.org/differential/revision/edit/18880/
llvm-svn: 265858
This code was getting evaluated unintentionally at binding
generation time instead of binding file compilation time.
Addresses:
https://bugs.swift.org/browse/SR-1192
llvm-svn: 265829
The Python import works by ensuring the directory of the module or package is in sys.path, and then it does a Python `import foo`. The original code was not escaping the backslashes in the directory path, so this wasn't working.
Differential Revision: http://reviews.llvm.org/D18873
llvm-svn: 265738
os to "ios" or "macosx" if it is unspecified. For environments
where there genuinely is no os, we don't want to errantly
convert that to ios/macosx, e.g. bare board debugging.
Change PlatformRemoteiOS, PlatformRemoteAppleWatch, and
PlatformRemoteAppleTV to not create themselves if we have
an unspecified OS. Same problem - these are not appropriate
platforms for bare board debugging environments.
Have Process::Attach's logging take place if either
process or target logging is enabled.
<rdar://problem/25592378>
llvm-svn: 265732
In turns out this does make a functional change, in case when the inferior hits an int3 that was
not placed by the debugger. Backing out for now.
llvm-svn: 265647
TargetOptions is ambiguous due to a definition in LLVM and in clang. This was
exposed by SVN r265640. Update to fix the build against the newer revision.
llvm-svn: 265644
Summary:
SetThreadStopInfo was checking for a breakpoint at the current PC several times. This merges the
identical code into a separate function. I've left one breakpoint check alone, as it was doing
more complicated stuff, and it did not see a way to merge that without making the interface
complicated. NFC.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18819
llvm-svn: 265560
Summary:
This resolves a similar problem as D16720 (which handled the case when we single-step onto a
breakpoint), but this one deals with involutary stops: when we stop a thread (e.g. because
another thread has hit a breakpont and we are doing a full stop), we can end up stopping it right
before it executes a breakpoint instruction. In this case, the stop reason will be empty, but we
will still step over the breakpoint when do the next resume, thereby missing a breakpoint hit.
I have observed this happening in TestConcurrentEvents, but I have no idea how to reproduce this
behavior more reliably.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18692
llvm-svn: 265525
This test sets the compiler optimization level to -O1 and
makes some assumptions about how local frame vars will be
stored (i.e. in registers). These assumptions are not always
true.
I did a first-pass set of improvements that:
(1) no longer assumes that every one of the target locations has
every variable in a register. Sometimes the compiler
is even smarter and skips the register entirely.
(2) simply expects one of the 5 or so variables it checks
to be in a register.
This test probably passes on a whole lot more systems than it
used to now. This is certainly true on OS X.
llvm-svn: 265498
Summary:
The '-p' option for dotest.py was ignored in multiprocess mode,
as the -p argument to the inferior would overwrite the -p argument
passed on the command line.
Reviewers: zturner, tfiala
Subscribers: lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D18779
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 265422
Summary: Flag updated in D233237
Reviewers: spyffe, jingham, Eugene.Zelenko
Subscribers: lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D18660
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 265421
Summary: Print environment from triple if it exists.
Reviewers: tfiala, clayborg
Subscribers: lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D18620
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 265420
Summary:
The logic to read modules from memory was added to LoadModuleAtAddress
in the dynamic loader, but not in process gdb remote. This means that when
the remote uses svr4 packets to give library info, libraries only present
on the remote will not be loaded.
This patch therefore involves some code duplication from LoadModuleAtAddress
in the dynamic loader, but removing this would require some amount of code
refactoring.
Reviewers: ADodds, tberghammer, tfiala, deepak2427, ted
Subscribers: tfiala, lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D18531
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 265418
Previously we had 3 different method to run shell commands on the
target and 4 copy of code waiting until a given file appears on the
target device (used for syncronization). This CL merges these methods
to 1 run_platform_command and 1 wait_for_file_on_target functions
located in some utility classes.
Differential revision: http://reviews.llvm.org/D18789
llvm-svn: 265398
Summary:
There was a bug in linux core file handling, where if there was a running process with the same
process id as the id in the core file, the core file debugging would fail, as we would pull some
pieces of information (ProcessInfo structure) from the running process instead of the core file.
I fix this by routing the ProcessInfo requests through the Process class and overriding it in
ProcessElfCore to return correct data.
A (slightly convoluted) test is included.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18697
llvm-svn: 265391
in thumb mode into one method in ArchSpec, replace checks for
specific cores in the disassembler with calls to this. Also call
this from the arm instruction emulation code.
The determination of whether a given ArchSpec is thumb-only is still
a bit of a hack, but at least the hack is consolidated into a single
place. In my original version of this patch http://reviews.llvm.org/D13578
I was calling into llvm's feature arm feature tables to make this
determination, like
#include "llvm/Support/TargetRegistry.h"
#include "llvm/MC/MCSubtargetInfo.h"
#include "llvm/../../lib/Target/ARM/ARMGenRegisterInfo.inc"
#include "llvm/../../lib/Target/ARM/ARMFeatures.h"
[...]
std::string triple (GetTriple().getTriple());
const char *cpu = "";
const char *features_str = "";
const llvm::Target *curr_target = llvm::TargetRegistry::lookupTarget(triple.c_str(), Error);
std::unique_ptr<llvm::MCSubtargetInfo> subtarget_info_up (curr_target->createMCSubtargetInfo(triple.c_str(), cpu, features_str));
if (subtarget_info_up->getFeatureBits()[llvm::ARM::FeatureNoARM])
{
return true;
}
but those tables are post-llvm-build generated and linking against them
for all of our different build system methods was a big hiccup that I
haven't had time to revisit convincingly.
I'll keep that reviews.llvm.org patch around to remind myself that I
need to take another run at linking against the necessary tables
again in llvm.
<rdar://problem/23022803>
llvm-svn: 265377
Teach LLDB that different shells have different characters they are sensitive to, and use that knowledge to do shell-aware escaping
This helps solve a class of problems on OS X where LLDB would try to launch via sh, and run into problems if the command line being passed to the inferior contained such special markers (hint: the shell would error out and we'd fail to launch)
This makes those launch scenarios work transparently via shell expansion
Slightly improve the error message when this kind of failure occurs to at least suggest that the user try going through 'process launch' directly
Fixes rdar://problem/22749408
llvm-svn: 265357
$(LLDB_PYTHON_TESTSUITE_CC) defaults to the just-built clang. Together
with changes to the zorg repo, this enables the Green Dragon LLDB OS X
Xcode-based builder to run the new TSAN LLDB tests.
llvm-svn: 265315
Summary:
Even though FileSpec attempted to handle both kinds of path syntaxes (posix and windows) on both
platforms, it relied on the llvm path library to do its work, whose behavior differed on
different platforms. This led to subtle differences in FileSpec behavior between platforms. This
replaces the pieces of the llvm library with our own implementations. The functions are simply
copied from llvm, with #ifdefs replaced by runtime checks for ePathSyntaxWindows.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18689
llvm-svn: 265299
This addresses the same problem as r264846 (the test not expecting the situation when two thread
hit the watchpoint simultaneously), but for a different test.
llvm-svn: 265294
In doing so, two bugs were uncovered (and fixed). The first bug
is that ClangASTContext::RemoveFastQualifiers() was broken, and
was not removing fast qualifiers (or doing anything else for that
matter). The second bug is that UnifyAccessSpecifiers treated
AS_None asymmetrically, which is probably an edge case, but seems
like a bug nonetheless.
llvm-svn: 265200
TypeSP SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext (const DWARFDeclContext &dwarf_decl_ctx);
The problem was we might be looking for a type "Foo", and find one from another langauge. Then the DWARFASTParserClang would try to make an AST type using a CompilerType that might return an empty.
This fix makes sure that when we create a DWARFDeclContext from a DWARFDIE that the DWARFDeclContext we set the language of the DIE. Then when we go to find matches for DWARFDeclContext, we end up with bunch of DIEs. We check each DWARFDIE that we found by asking it for its language and making sure the language is compatible with the type system that we want to use. This keeps us from using the wrong types to resolve forward declarations.
<rdar://problem/25276165>
llvm-svn: 265196
Enrico has a bug on him to make this work across older libcxx list
and newer libcxx list simultaneously. Needed in preparation of
getting the OS X public CI to run the TSAN tests.
tracked by:
rdar://25499635
llvm-svn: 265188
rnb_err_t
RNBRemote::HandlePacket_stop_process (const char *p)
{
if (!DNBProcessInterrupt(m_ctx.ProcessID()))
HandlePacket_last_signal (NULL);
return rnb_success;
}
In the call to DNBProcessInterrupt we did:
nub_bool_t
DNBProcessInterrupt(nub_process_t pid)
{
MachProcessSP procSP;
if (GetProcessSP (pid, procSP))
return procSP->Interrupt();
return false;
}
This would always return false. It would cause HandlePacket_stop_process to always call "HandlePacket_last_signal (NULL);" which would send an extra stop reply packet _if_ the process is stopped. On a machine with enough cores, it would call DNBProcessInterrupt(...) and then HandlePacket_last_signal(NULL) so quickly that it will never send out an extra stop reply packet. But if the machine is slow enough or doesn't have enough cores, it could cause the call to HandlePacket_last_signal() to actually succeed and send an extra stop reply packet. This would cause problems up in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() where it would get the first stop reply packet and then possibly return or execute an async packet. If it returned, then the next packet that was sent will get the second stop reply as its response. If it executes an async packet, the async packet will get the wrong response.
To fix this I did the following:
1 - in debugserver, I fixed "bool MachProcess::Interrupt()" to return true if it sends the signal so we avoid sending the stop reply twice on slower machines
2 - Added a log line to RNBRemote::HandlePacket_stop_process() to say if we ever send an extra stop reply so we will see this in the darwin console output if this does happen
3 - Added response validators to StringExtractorGDBRemote so that we can verify some responses to some packets.
4 - Added validators to packets that often follow stop reply packets like the "m" packet for memory reads, JSON packets since "jThreadsInfo" is often sent immediately following a stop reply.
5 - Modified GDBRemoteCommunicationClient::SendPacketAndWaitForResponseNoLock() to validate responses. Any "StringExtractorGDBRemote &response" that contains a valid response verifier will verify the response and keep looking for correct responses up to 3 times. This will help us get back on track if we do get extra stop replies. If a StringExtractorGDBRemote does not have a response validator, it will accept any packet in response.
6 - In GDBRemoteCommunicationClient::SendPacketAndWaitForResponse we copy the response validator from the "response" argument over into m_async_response so that if we send the packet by interrupting the running process, we can validate the response we actually get in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse()
7 - Modified GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() to always check for an extra stop reply packet for 100ms when the process is interrupted. We were already doing this because we might interrupt a process with a \x03 packet, yet the process was in the process of stopping due to another reason. This race condition could cause an extra stop reply packet because the GDB remote protocol says if a \x03 packet is sent while the process is stopped, we should send a stop reply packet back. Now we always check for an extra stop reply packet when we manually interrupt a process.
The issue was showing up when our IDE would attempt to set a breakpoint while the process is running and this would happen:
--> \x03
<-- $T<stop reply 1>
--> z0,AAAAA,BB (set breakpoint)
<-- $T<stop reply 1> (incorrect extra stop reply packet)
--> c
<-- OK (response from z0 packet)
Now all packet traffic was off by one response. Since we now have a validator on the response for "z" packets, we do this:
--> \x03
<-- $T<stop reply 1>
--> z0,AAAAA,BB (set breakpoint)
<-- $T<stop reply 1> (Ignore this because this can't be the response to z0 packets)
<-- OK -- (we are back on track as this is a valid response to z0)
...
As time goes on we should add more packet validators.
<rdar://problem/22859505>
llvm-svn: 265086
Summary:
Debug info is used only by the client and lldb-server tests do not even have the client component
running, as they communicate with the server directly. Therefore, running the tests for each
debug info type is unnecessarry.
This adds general ability to mark a test class as not dependent on debug info, and marks all
lldb-server tests as such.
Reviewers: tberghammer, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18598
llvm-svn: 265017
Summary:
In case of Dwo, DIERef stores a compile unit offset in the main object file, and not in the dwo.
The implementation of SymbolFileDWARFDwo::GetDIE inherited from SymbolFileDWARF tried to lookup
the compilation unit in the DWO based on the main object file offset (and failed). I change the
implementation to verify the DIERef indeed references compile unit belonging to this dwo and then
lookup the die based on the die offset alone.
Includes a couple of fixes for mismatched struct/class tags.
Reviewers: tberghammer, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18646
llvm-svn: 265011
Ed Maste