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:
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
1 - DWARF in .o files with debug map in executable: we would place the compile unit index in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset
2 - DWO: we would place the compile unit offset in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset
There was a mixing and matching of this and it wasn't done consistently.
Major changes include:
The DIERef constructor that takes a lldb::user_id_t now requires a SymbolFileDWARF:
DIERef(lldb::user_id_t uid, SymbolFileDWARF *dwarf)
It is needed so that it can be decoded correctly. If it is DWARF in .o files with debug map in executable, then we get the right compile unit from the SymbolFileDWARFDebugMap, otherwise, we use the compile unit offset and DIE offset for DWO or normal DWARF.
The function:
lldb::user_id_t DIERef::GetUID() const;
Now becomes
lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf) const;
Again, we need the DWARF file to encode it correctly.
This removes the need for "lldb::user_id_t SymbolFileDWARF::MakeUserID() const" and for bool SymbolFileDWARF::UserIDMatches (lldb::user_id_t uid) const". There were also many places were doing things inneficiently like:
1 - encode a dw_offset_t into a lldb::user_id_t
2 - call the public SymbolFile interface to resolve types using the lldb::user_id_t
3 - This would then decode the lldb::user_id_t into a DIERef, and then try to find that type.
There are many places that are now doing this more efficiently by storing DW_AT_type form values as DWARFFormValue objects and then making a DIERef from them and directly calling the underlying function to resolve the lldb_private::Type, lldb_private::CompilerType, lldb_private::CompilerDecl, lldb_private::CompilerDeclContext.
If there are any regressions in DWARF with DWO, we will need to fix any issues that arise since the original patch wasn't functional for the much more widely used DWARF in .o files with debug map.
<rdar://problem/25200976>
llvm-svn: 264909
The problem was that the static DynamicLoaderDarwinKernel::Initialize() was recently changed to come before DynamicLoaderMacOSXDYLD::Initialize() which caused the DynamicLoaderDarwinKernel::CreateInstance(...) to be called before DynamicLoaderMacOSXDYLD::CreateInstance(...) and DynamicLoaderDarwinKernel would claim it could be the dynamic loader for a user space MacOSX process. The fix is to make DynamicLoaderDarwinKernel::CreateInstance() a bit more thourough when vetting the process so that it doesn't claim MacOSX user space processes.
<rdar://problem/25425373>
llvm-svn: 264794
quietly apply fixits for those who really trust clang's fixits.
Also, moved the retry into ClangUserExpression::Evaluate, where I can make a whole new ClangUserExpression
to do the work. Reusing any of the parts of a UserExpression in situ isn't supported at present.
<rdar://problem/25351938>
llvm-svn: 264793
Summary:
Since r264316, clang started adding DW_AT_GNU_dwo_name attribute to dwo files (previously, this
attribute was only present in main object files), breaking pretty much every dwo test. The
problem was that we were treating the presence of said attribute as a signal that we should look
for information in an external object file, and caused us to enter an infinite loop. I fix this
by making sure we do not go looking for an external dwo file if we already *are* parsing a dwo
file.
Reviewers: tberghammer, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18547
llvm-svn: 264729
This allows these functions to be re-used by a forthcoming
PDBASTParser. The functions in question are CanCompleteType,
CompleteType, and CanImport. Conceptually, these functions belong
on ClangASTImporter anyway, and previously they were just ping
ponging around through a few levels of indirection to end up there
as well, so this patch actually makes the code somewhat simpler.
A few methods were moved to a new file called ClangUtil, so that
they can be shared between ClangASTImporter and ClangASTContext
without creating a circular dependency between those two cpp
files.
Differential Revision: http://reviews.llvm.org/D18381
llvm-svn: 264685
Blocks and lambdas have their implementation functions stored in the IR for an
expression. If we put the block/lambda into a result variable it needs to stay
around. As a heuristic, remember any execution unit that has more than one
function in it.
<rdar://problem/22864976>
llvm-svn: 264483
months back to PlatformRemoteAppleTV and PlatformRemoteAppleWatch
to help understand what's happening when lldb can't find binaries
that it should be finding.
llvm-svn: 264380
This feature is controlled by an expression command option, a target property and the
SBExpressionOptions setting. FixIt's are only applied to UserExpressions, not UtilityFunctions,
those you have to get right when you make them.
This is just a first stage. At present the fixits are applied silently. The next step
is to tell the user about the applied fixit.
<rdar://problem/25351938>
llvm-svn: 264379
Summary:
Fixes SBCommandReturnObject::SetImmediateOutputFile() and
SBCommandReturnObject::SetImmediateOutputFile() for files opened
with "a" or "a+" by resolving inconsistencies between File and
our Python parsing of file objects.
Reviewers: granata.enrico, Eugene.Zelenko, jingham, clayborg
Subscribers: lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D18228
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 264351
Summary:
Though r264012 was fancy enough to make reading the jit entry struct
work with templates, the packing and alignment attributes do not work on
Windows. So, this change makes it plain and simple with manual reading
of the jit entry struct.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18379
llvm-svn: 264217
This patch adds ThreadSanitizer support into LLDB:
- Adding a new InstrumentationRuntime plugin, ThreadSanitizerRuntime, in the same way ASan is implemented.
- A breakpoint stops in `__tsan_on_report`, then we extract all sorts of information by evaluating an expression. We then populate this into StopReasonExtendedInfo.
- SBThread gets a new API, SBThread::GetStopReasonExtendedBacktraces(), which returns TSan’s backtraces in the form of regular SBThreads. Non-TSan stop reasons return an empty collection.
- Added some test cases.
Reviewed by Greg Clayton.
llvm-svn: 264162
This patch adds a new ExecutionPolicy, eExecutionPolicyTopLevel, which
tells the expression parser that the expression should be JITted as top
level code but nothing (except static initializers) should be run. I
have modified the Clang expression parser to recognize this execution
policy. On top of the existing patches that support storing IR and
maintaining a map of arbitrary Decls, this is mainly just patching up a
few places in the expression parser.
I intend to submit a patch for review that exposes this functionality
through the "expression" command and through the SB API. That patch
also includes a testcase for all of this.
<rdar://problem/22864976>
llvm-svn: 264095
Win32 API calls that are Unicode aware require wide character
strings, but LLDB uses UTF8 everywhere. This patch does conversions
wherever necessary when passing strings into and out of Win32 API
calls.
Patch by Cameron
Differential Revision: http://reviews.llvm.org/D17107
Reviewed By: zturner, amccarth
llvm-svn: 264074
IRExecutionUnits contain code and data that persistent declarations can
depend on. In order to keep them alive and provide for lookup of these
symbols, we now allow any PersistentExpressionState to keep a list of
execution units. Then, when doing symbol lookup on behalf of an
expression, any IRExecutionUnit can consult the persistent expression
states on a particular Target to find the appropriate symbol.
<rdar://problem/22864976>
llvm-svn: 263995
a way for compilation to take a "thread to use for compilation". If it isn't set then the
compilation will use the currently selected thread. This should help keep function execution
to the one thread intended.
llvm-svn: 263972
Persistent decls have traditionally only been types. However, we want to
be able to persist more things, like functions and global variables. This
changes some of the nomenclature and the lookup rules to make this possible.
<rdar://problem/22864976>
llvm-svn: 263864
We want to do a better job presenting errors that occur when evaluating
expressions. Key to this effort is getting away from a model where all
errors are spat out onto a stream where the client has to take or leave
all of them.
To this end, this patch adds a new class, DiagnosticManager, which
contains errors produced by the compiler or by LLDB as an expression
is created. The DiagnosticManager can dump itself to a log as well as
to a string. Clients will (in the future) be able to filter out the
errors they're interested in by ID or present subsets of these errors
to the user.
This patch is not intended to change the *users* of errors - only to
thread DiagnosticManagers to all the places where streams are used. I
also attempt to standardize our use of errors a bit, removing trailing
newlines and making clients omit 'error:', 'warning:' etc. and instead
pass the Severity flag.
The patch is testsuite-neutral, with modifications to one part of the
MI tests because it relied on "error: error:" being erroneously
printed. This patch fixes the MI variable handling and the testcase.
<rdar://problem/22864976>
llvm-svn: 263859
Summary:
This also adds a basic smoke test for linux core file reading. I'm checking in the core files as
well, so that the tests can run on all platforms. With some tricks I was able to produce
reasonably-sized core files (~40K).
This fixes the first part of pr26322.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18176
llvm-svn: 263628
This can cause differences in which bit patterns end up meaning YES or NO. In general, however, 0 == NO and 1 == YES.
To keep it simple, LLDB will now show "YES" and "NO" only for 1 and 0 respectively, and format other values as the plain numeric value instead.
Fixes rdar://24809994
llvm-svn: 263604
Build-id support is being added to lld and by default it may produce a
64-bit build-id.
Prior to this change lldb would reject such a build-id. However, it then
falls back to a 4-byte crc32, which is a poorer quality identifier.
Differential Revision: http://reviews.llvm.org/D18096
llvm-svn: 263432
Turns out that most of the code that runs expressions (e.g. the ObjC runtime grubber) on
behalf of the expression parser was using the currently selected thread. But sometimes,
e.g. when we are evaluating breakpoint conditions/commands, we don't select the thread
we're running on, we instead set the context for the interpreter, and explicitly pass
that to other callers. That wasn't getting communicated to these utility expressions, so
they would run on some other thread instead, and that could cause a variety of subtle and
hard to reproduce problems.
I also went through the commands and cleaned up the use of GetSelectedThread. All those
uses should have been trying the thread in the m_exe_ctx belonging to the command object
first. It would actually have been pretty hard to get misbehavior in these cases, but for
correctness sake it is good to make this usage consistent.
<rdar://problem/24978569>
llvm-svn: 263326
Removed lldb_private::File::Duplicate() and the copy constructor and the assignment operator that used to duplicate the file handles and made them private so no one uses them. Previously the lldb_private::File::Duplicate() function duplicated files that used file descriptors, (int) but not file streams (FILE *), so the lldb_private::File::Duplicate() function only worked some of the time. No one else excep thee ScriptInterpreterPython was using these functions, so that aren't needed nor desired. Previously every time you would drop into the python interpreter we would duplicate files, and now we avoid this file churn.
<rdar://problem/24877720>
llvm-svn: 263161
Fix a problem raised with the previous patches being applied in the wrong order.
Committed on behalf of: Dean De Leo <dean@codeplay.com>
llvm-svn: 263134
This commit implements the reading of stack spilled function arguments for little endian MIPS targets.
Committed on behalf of: Dean De Leo <dean@codeplay.com>
llvm-svn: 263131
This commit implements the reading of stack spilled function arguments for little endian MIPS targets.
Committed on behalf of: Dean De Leo <dean@codeplay.com>
llvm-svn: 263130
Currently it is not specified, and since allocations are usually
requested once we hit a renderscript breakpoint, the language will be
inferred being as renderscript by the ExpressionParser.
Actually allocations attempt to invoke functions part of the RS runtime,
written in C/C++, so evaluating the calls in RenderScript could be
misleading.
In particular, in MIPS, the ABI between C/C++ (mips o32) and
renderscript (arm) might introduce subtle bugs when evaluating such
expressions.
This change explicitly sets the language used to evaluate the allocations
as C++.
Committed on behalf of: Dean De Leo <dean@codeplay.com>
llvm-svn: 263129
The current expression language is currently tracked in a few places within the ClangExpressionParser constructor.
This patch adds a private lldb::LanguageType attribute to the ClangExpressionParser class and tracks the expression language from that one place.
Author: Luke Drummond <luke.drummond@codeplay.com>
Differential Revision: http://reviews.llvm.org/D17719
llvm-svn: 263099
Summary:
GCC does not emit DW_AT_data_member_location for members of a union.
Starting with a 0 value for member locations helps is reading union types
in such cases.
Reviewers: clayborg
Subscribers: ldrumm, lldb-commits
Differential Revision: http://reviews.llvm.org/D18008
llvm-svn: 263085
Previously line table parsing code assumed that the only gaps would
occur at the end of functions. In practice this isn't true, so this
patch makes the line table parsing more robust in the face of
functions with non-contiguous byte arrangements.
llvm-svn: 263078
That way you can set offset breakpoints that will move as the function they are
contained in moves (which address breakpoints can't do...)
I don't align the new address to instruction boundaries yet, so you have to get
this right yourself for now.
<rdar://problem/13365575>
llvm-svn: 263049
to each other. This should remove some infrequent teardown crashes when the
listener is not the debugger's listener.
Processes now need to take a ListenerSP, not a Listener&.
This required changing over the Process plugin class constructors to take a ListenerSP, instead
of a Listener&. Other than that there should be no functional change.
<rdar://problem/24580184> CrashTracer: [USER] Xcode at …ework: lldb_private::Listener::BroadcasterWillDestruct + 39
llvm-svn: 262863
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
Previously we were using thumbv7 and armv8.1a what ended up showing a
few undefined instruction when disassembling code. This CL update the
architectures used to armv8.2a and thumbv8.2a (newest available) so we
display all instruction in the disassambly.
llvm-svn: 262482
This is a mechanical refactor. There should be no functional changes in this commit.
Instead of encapsulating just the Windows-specific data, ProcessWinMiniDump now uses a private implementation class. This reduces indirections (in the source). It makes it easier to add private helper methods without touching the header and allows them to have platform-specific types as parameters. The only trick was that the pimpl class needed a back pointer in order to call a couple methods.
llvm-svn: 262256
The purpose of these plugins is to make LLDB capable of debugging java
code JIT-ed by the android runtime.
Differential revision: http://reviews.llvm.org/D17616
llvm-svn: 262015
Additionally fix the type of some dwarf expression where we had a
confusion between scalar and load address types after a dereference.
Differential revision: http://reviews.llvm.org/D17604
llvm-svn: 262014
Most address represented in lldb as section plus offset and handling of
absolute addresses is problematic in several location because of lack
of necessary information (e.g. Target) or because of performance issues.
This CL change the way ObjectFileELF handle the absolute symbols with
creating a pseudo section for each symbol. With this change all existing
code designed to work with addresses in the form of section plus offset
will work with absolute symbols as well.
Differential revision: http://reviews.llvm.org/D17450
llvm-svn: 261859
DWARF stores this information in the DW_AT_start_scope attribute. This
CL add support for this attribute and also changes the functions
displaying frame variables to only display the variables currently in
scope.
Differential revision: http://reviews.llvm.org/D17449
llvm-svn: 261858
32-bit processes on 64-bit Windows run in a layer called WoW64 (Windows-on-Windows64). If you capture a mini dump of such a process from a 32-bit debugger, you end up with a register context for the 64-bit WoW64 process rather than the 32-bit one you probably care about.
This detects WoW64 by looking to see if there's a module named wow64.dll loaded. For such processes, it then looks in the 64-bit Thread Environment Block (TEB) to locate a copy of the 32-bit CONTEXT record that the plugin needs for the register context.
Added some rudimentary tests. I'd like to improve these later once we figure out how to get the exception information from these mini dumps.
Differential Revision: http://reviews.llvm.org/D17465
llvm-svn: 261808
Mips64 tests were failing on windows because the sscanf implementation differs between clang/gcc/msvc such that on windows %lx specifies a 32bits parameter and %llx is for 64bits. For us this meant that 64bit pointers were being truncated to 32bits on their way into a JIT'd expression.
llvm-svn: 261741
Summary:
On arm64, linux<=4.4 and Android<=M there is a bug, which prevents single-stepping from working when
the system comes back from suspend, because of incorrectly initialized CPUs. This did not really
affect Android<M, because it did not use software suspend, but it is a problem for M, which uses
suspend (doze) quite extensively. Fortunately, it seems that the first CPU is not affected by
this bug, so this commit implements a workaround by forcing the inferior to execute on the first
cpu whenever we are doing single stepping.
While inside, I have moved the implementations of Resume() and SingleStep() to the thread class
(instead of process).
Reviewers: tberghammer, ovyalov
Subscribers: aemerson, rengolin, tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D17509
llvm-svn: 261636
Summary:
Signalfd is not used in the code anymore, and given that the same functionality can be achieved
with the new MainLoop class, it's unlikely we will need it in the future. Remove all traces of
it.
Reviewers: tberghammer, ovyalov
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D17510
llvm-svn: 261631
Inline functions in DWARF have AT_abstract_origin set, but we only handled that
if the functions were C++ methods. Inline functions -- C or C++ -- have this
also, and as a result they got one FunctionDecl for each inlined instance. When
going to construct the locals, this meant that the arguments (which did properly
have their abstract origins handled) would get associated with the master
FunctionDecl, and the inlined FunctionDecls would all appear to have no locals.
This manifested as not being able to look up local variables when stopped in an
inline fuunction. We should have had a test for this, but somewhere along the
line the relevant test case lost its .py file (or it never had one).
This patch fixes this problem and restores the .py file.
<rdar://problem/24712434>
llvm-svn: 261598
This patch aims to reduce the code duplication among all of the platforms in GetSoftwareBreakpointTrapOpcode by pushing all common code into the Platform base class.
Differential Revision: http://reviews.llvm.org/D17395
llvm-svn: 261536
This patches does the following:
+ fix return type: ClangExpressionParser::Parse returns unsigned, but was actually returning a signed value, num_errors.
+ use helper clang::TextDiagnosticBuffer::getNumErrors() instead of counting the errors ourself.
+ limit scoping of block-level automatic variables as much as practical.
+ remove reused multipurpose TextDiagnosticBuffer::const_iterator in favour of loop-scoped err, warn, and note variables in the diagnostic printing code.
+ refactor diagnostic printing loops to use a proper loop invariant.
Author: Luke Drummond <luke.drummond@codeplay.com>
Differential Revision: http://reviews.llvm.org/D17273
llvm-svn: 261345
[git 65dafa83] introduced the GetBuiltinIncludePath function copied from cfe/lib/Driver/CC1Options.cpp
This function is no longer used in lldb's expression parser and I believe it is safe to remove it.
Author: Luke Drummond <luke.drummond@codeplay.com>
Differential Revision: http://reviews.llvm.org/D17266
llvm-svn: 261328
This change is improving the instruction emulation based unwinding to
handle when the frame pointer is adjusted (increment/decrement) after
it has been initialized. The situation can occur in the prologue of
some function where FP is adjusted before it is copied back to SP.
Example code (thumb, generated by gcc 4.8):
< +0>: push {r4, r7, lr}
< +2>: sub sp, #0x14
< +4>: add r7, sp, #0x0
...
<+50>: adds r7, #0x14 ; The CL fixes the handling of this instruction
<+52>: mov sp, r7 ; Previously unwinding from here was broken
<+54>: pop {r4, r7, pc}
Differential revision: http://reviews.llvm.org/D17295
llvm-svn: 261318
on attach uses the architecture it has figured out, rather than the Target's
architecture, which may not have been updated to the correct value yet.
<rdar://problem/24632895>
llvm-svn: 261279
SUMMARY:
This patch implements ArchSpec::GetClangTargetCPU() that provides string representing current architecture as a target CPU.
This string is then passed to tools like clang so that they generate correct code for that target.
Reviewers: clayborg, zturner
Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits
Differential Revision: http://reviews.llvm.org/D17022
llvm-svn: 261206
* Generate artificial symbol names from eh_fame during symbol parsing
so these symbols are already present when we calcualte the size of
the symbols where 0 is specified.
* Fix symbol size calculation for the last symbol in the file where
it have to last until the end of the parent section.
This is the re-commit of the original change after fixing some test
failures on OSX.
Differential revision: http://reviews.llvm.org/D16996
llvm-svn: 261205
This code was doing the right thing for the iOS simulator, but not other simulator platforms
Fix it by making the warning not happen for all platforms whose name ends in "-simulator"
Since this code lives in AppleObjCRuntimeV2.cpp, this already only applies to Apple platforms by definition, so I am not too worried about conflicts with other vendors
llvm-svn: 261165
This reverts commit 293c18e067d663e0fe93e6f3d800c2a4bfada2b0.
The BKPT instruction generates SIGBUS instead of SIGTRAP in the Linux
kernel on Nexus 6 - 5.1.1 (kernel version 3.10.40). Revert the CL
until we can figure out how can we hanble the SIGBUS or how to get
back a SIGTRAP using the BKPT instruction.
llvm-svn: 260969
the xcode project file to catch switch statements that have a
case that falls through unintentionally.
Define LLVM_FALLTHROUGH to indicate instances where a case has code
and intends to fall through. This should be in llvm/Support/Compiler.h;
Peter Collingbourne originally checked in there (r237766), then
reverted (r237941) because he didn't have time to mark up all the
'case' statements that were intended to fall through. I put together
a patch to get this back in llvm http://reviews.llvm.org/D17063 but
it hasn't been approved in the past week. I added a new
lldb-private-defines.h to hold the definition for now.
Every place in lldb where there is a comment that the fall-through
is intentional, I added LLVM_FALLTHROUGH to silence the warning.
I haven't tried to identify whether the fallthrough is a bug or
not in the other places.
I haven't tried to add this to the cmake option build flags.
This warning will only work for clang.
This build cleanly (with some new warnings) on macosx with clang
under xcodebuild, but if this causes problems for people on other
configurations, I'll back it out.
llvm-svn: 260930
case where a core file has a kernel binary and a user
process dyld in the same one. Without this, we were
always picking the dyld and trying to process it as a
kernel.
<rdar://problem/24446112>
llvm-svn: 260803
Since IRExecutionUnit is now capable of looking up symbols, and the JIT is up to
the task of generating the appropriate relocations, we don't need to do all the
work that IRForTarget used to do to fixup symbols at the IR level.
We also don't need to allocate data manually (with its attendant bugs) because
the JIT is capable of doing so without crashing.
We also don't need the awkward lldb.call.realName metadata to determine what
calls are objc_msgSend, because they now just reference objc_msgSend.
To make this work, we ensure that we recognize which symbols are extern "C" and
report them to the compiler as such. We also report the full Decl of functions
rather than just making up top-level functions with the appropriate types.
This should not break any testcases, but let me know if you run into any issues.
<rdar://problem/22864926>
llvm-svn: 260768
On libc++ std::atomic is a fairly simple data type (layout wise, at least), wrapping actual contents in a member variable named "__a_"
All the formatters are doing is "peel away" this intermediate layer and exposing user data as direct children or values of the std::atomic root variable
Fixes rdar://24329405
llvm-svn: 260752
I'm preparing to remove symbol lookup from IRForTarget, where it constitutes a
dreadful hack working around no-longer-existing JIT bugs. Thanks to our
contributors, IRForTarget has a lot of smarts that IRExecutionUnit doesn't have,
so I've cleaned them up a bit and moved them over to IRExecutionUnit.
Also for historical reasons, IRExecutionUnit used the "Small" code model on non-
ELF platforms (namely, OS X). That's no longer necessary, and we can use the
same code model as everyone else on OS X. I've fixed that.
llvm-svn: 260734
However, they also contain fallback logic that - in cases where LLDB can't recognize the specific subclass - actually does run code in order to inspect those objects.
The argument for this logic was that these data types are critical enough that the risk of getting it wrong is outweighed by the advantage of always providing accurate child information.
Practical experience however shows that "po" - a code running data-inspection command - is quite frequently used, and not considered burdensome by users.
As such, this makes the code-running fallback in the data formatters a risk that carries very little actual reward. Also, unlike the time this code was originally written, we now have accurate class information for Objective-C, and thus we are less likely to improperly identify classes.
This commit removes support for the code-running fallback, and aligns the data formatters for NSArray, NSDictionary and NSSet to the general no-code-running behavior of other data formatters.
While it is possible for us to add support for some subclasses that are now no longer covered by static inspection alone, this is beyond the scope of this commit.
llvm-svn: 260664
assert(((SymbolFileDWARF*)m_ast.GetSymbolFile())->UserIDMatches(die.GetDIERef().GetUID()) &&
"Adding incorrect type to forward declaration map");
The problem is that "m_ast.GetSymbolFile()" can return a SymbolFileDWARFDebugMap. The code is doing the right thing if the assertion is ignored.
<rdar://problem/24437972>
llvm-svn: 260618
In some circumstances (notably, certain minidumps), the thread CONTEXT does not have values for the
control registers (EIP, ESP, EBP, EFLAGS). There are flags in the CONTEXT which indicate which
portions are valid, but those flags weren't checked. The old code would not detect this and give a
garbage value for the register. The new code will log the problem and return an error.
I consolidated the error checking and logging into a helper function, which makes the big switch
statement easier to read and verify.
Ran tests to ensure this doesn't break anything. Manually verified that a minidump without info on
the control registers now indicates the problem instead of giving bad information.
Differential Review: http://reviews.llvm.org/D17152
llvm-svn: 260559
This patch reworks the function argument reading code, allowing us to annotate arguments with their types. The type/size information is needed to correctly parse arguments passed on the stack.
llvm-svn: 260525
llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files
Each time a SymbolFile::FindTypes() is called, it needs to check the searched_symbol_files list to make sure it hasn't already been asked to find the type and return immediately if it has been checked. This will stop circular dependencies from also crashing LLDB during type queries.
This has proven to be an issue when debugging large applications on MacOSX that use DWARF in .o files.
<rdar://problem/24581488>
llvm-svn: 260434
* Generate artificial symbol names from eh_fame during symbol parsing
so these symbols are already present when we calcualte the size of
the symbols where 0 is specified.
* Fix symbol size calculation for the last symbol in the file where
it have to last until the end of the parent section.
Differential revision: http://reviews.llvm.org/D16996
llvm-svn: 260369
The IT instruction can specify condition code for up to 4 consecutive
instruction and it is used quite often by clang in epilogues causing
an issue when trying to unwind from locations covered by the IT
instruction and for locatins inmediately after the IT instruction.
Changes made to fix it:
* Introduce the concept of conditional instruction block what is a list
of consecutive instructions with the same condition. We update the
unwind information during the conditional instruction block and when
we reach the end of it (first instruction with a differemt condition)
then we restore the unwind information we had before the condition.
* Fix a bug in the ARM instruction emulator where neither PC nor the
ITSTATE was advanced when we reached an instruction what we can't
decode.
After the change we have no regression on android-arm running the
regular test suit and TestStandardUnwind also passes when running it
with clang as the compiler (previously it failed on an IT instruction).
Differential revision: http://reviews.llvm.org/D16814
llvm-svn: 260368
The UDF instruction is deprecated in armv7 and in case of thumb2
instructions set it don't work well together with the IT instruction.
Differential revision: http://reviews.llvm.org/D16853
llvm-svn: 260367
1) Turns out we weren't correctly uniquing types for C++. We would search our repository for "lldb_private::Process", but yet store just "Process" in the unique type map. Now we store things correctly and correctly unique types.
2) SymbolFileDWARF::CompleteType() can be called at any time in order to complete a C++ or Objective C class. All public inquiries into the SymbolFile go through SymbolVendor, and SymbolVendor correctly takes the module lock before it call the SymbolFile API call, but when we let CompilerType objects out in the wild, they can complete themselves at any time from the expression parser, so the ValueObjects or (SBValue objects in the public API), and many more places. So we now take the module lock when completing a type to avoid two threads being in the SymbolFileDWARF at the same time.
3) If a class has a template member function like:
class A
{
<template T>
void Foo(T t);
};
The DWARF will _only_ contain a DW_TAG_subprogram for "Foo" if anyone specialized it. This would cause a class definition for A inside a.cpp that used a "int" and "float" overload to look like:
class A
{
void Foo(int t);
void Foo(double t);
};
And a version from b.cpp that used a "float" overload to look like:
class A
{
void Foo(float t);
};
And a version from c.cpp that use no overloads to look like:
class A
{
};
Then in an expression if you have two variables, one name "a" from a.cpp in liba.dylib, and one named "b" from b.cpp in libb.dylib, you will get conflicting definitions for "A" and your expression will fail. This all stems from the fact that DWARF _only_ emits template specializations, not generic definitions, and they are only emitted if they are used. There are two solutions to this:
a) When ever you run into ANY class, you must say "just because this class doesn't have templatized member functions, it doesn't mean that any other instances might not have any, so when ever I run into ANY class, I must parse all compile units and parse all instances of class "A" just in case it has member functions that are templatized.". That is really bad because it means you always pull in ALL DWARF that contains most likely exact duplicate definitions of the class "A" and you bloat the memory that the SymbolFileDWARF plug-in uses in LLDB (since you pull in all DIEs from all compile units that contain a "A" definition) uses for little value most of the time.
b) Modify DWARF to emit generic template member function definitions so that you know from looking at any instance of class "A" wether it has template member functions or not. In order to do this, we would have to have the ability to correctly parse a member function template, but there is a compiler bug:
<rdar://problem/24515533> [PR 26553] C++ Debug info should reference DW_TAG_template_type_parameter
This bugs means that not all of the info needed to correctly make a template member function is in the DWARF. The main source of the problem is if we have DWARF for a template instantiation for "int" like: "void A::Foo<int>(T)" the DWARF comes out as "void A::Foo<int>(int)" (it doesn't mention type "T", it resolves the type to the specialized type to "int"). But if you actually have your function defined as "<template T> void Foo(int t)" and you only use T for local variables inside the function call, we can't correctly make the function prototype up in the clang::ASTContext.
So the best we can do for now we just omit all member functions that are templatized from the class definition so that "A" never has any template member functions. This means all defintions of "A" look like:
class A
{
};
And our expressions will work. You won't be able to call template member fucntions in expressions (not a regression, we weren't able to do this before) and if you are stopped in a templatized member function, we won't know that are are in a method of class "A". All things we should fix, but we need <rdar://problem/24515533> fixed first, followed by:
<rdar://problem/24515624> Classes should always include a template subprogram definition, even when no template member functions are used
before we can do anything about it in LLDB.
This bug mainly fixed the following Apple radar:
<rdar://problem/24483905>
llvm-svn: 260308
This is because PyThreadState_Get() assumes a non-NULL thread state and crashes otherwise; but PyThreadState_GET is just a shortcut (in non-Python-debugging builds) for the global variable that holds the thread state
The behavior of CTRL+C is slightly more erratic than one would like. CTRL+C in the middle of execution of Python code will cause that execution to be interrupted (e.g. time.sleep(1000)), but a CTRL+C at the prompt will just cause a KeyboardInterrupt and not exit the interpreter - worse, it will only trigger the exception once one presses ENTER.
None of this is optimal, of course, but I don't have a lot of time to appease the Python deities with the proper spells right now, and fixing the crasher is already a good thing in and of itself
llvm-svn: 260199
user process dyld binary and/or a mach kernel binary image. By
default, it prefers the kernel if it finds both.
But if it finds two kernel binary images (which can happen when
random things are mapped into memory), it may pick the wrong
kernel image.
DynamicLoaderDarwinKernel has heuristics to find a kernel in memory;
once we've established that there is a kernel binary in memory,
call over to that class to see if it can find a kernel address via
its search methods. If it does, use that.
Some minor cleanups to DynamicLoaderDarwinKernel while I was at it.
<rdar://problem/24446112>
llvm-svn: 259983
Obviously, if the original Debugger goes away, those commands are holding on to now stale memory, which has the potential to cause crashes
Fixes rdar://24460882
llvm-svn: 259964
This patch adds logic to detect if underlying binary is using arm hard float abi and use that information while handling return values in ABISysV_arm.
Differential revision: http://reviews.llvm.org/D16627
llvm-svn: 259885
Summary:
This reverts commit 8af14b5f9af68c31ac80945e5b5d56f0a14b38e4.
Reverting as it breaks a few tests on Mac.
Reviewers: spyffe
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16895
llvm-svn: 259823
Summary:
While evaluating expressions when stopped in a class method, there was a
problem of member variables hiding local variables. This was happening
because, in the context of a method, clang already knew about member
variables with their name and assumed that they were the only variables
with those names in scope. Consequently, clang never checks with LLDB
about the possibility of local variables with the same name and goes
wrong. This change addresses the problem by using an artificial
namespace "$__lldb_local_vars". All local variables in scope are
declared in the "$__lldb_expr" method as follows:
using $__lldb_local_vars::<local var 1>;
using $__lldb_local_vars::<local var 2>;
...
This hides the member variables with the same name and forces clang to
enquire about the variables which it thinks are declared in
$__lldb_local_vars. When LLDB notices that clang is enquiring about
variables in $__lldb_local_vars, it looks up local vars and conveys
their information if found. This way, member variables do not hide local
variables, leading to correct evaluation of expressions.
A point to keep in mind is that the above solution does not solve the
problem for one specific case:
namespace N
{
int a;
}
class A
{
public:
void Method();
int a;
};
void
A::Method()
{
using N::a;
...
// Since the above solution only touches locals, it does not
// force clang to enquire about "a" coming from namespace N.
}
Reviewers: clayborg, spyffe
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16746
llvm-svn: 259810
Patch replaces the --refresh flag removed in r258800 with it's own command, 'language renderscript allocation refresh'.
Since there is no reason this functionality should be tied to another command as an option.
The command itself simply re-JITs all our cached information about allocations.
llvm-svn: 259773
reason to None when we stop due to a trace, then noticed that
we were on a breakpoint that was not valid for the current thread.
That should actually have set it back to trace.
This was pr26441 (<rdar://problem/24470203>)
llvm-svn: 259684
Runtimes should be able to pass custom compilation options to the JIT for their stack frame. This patch adds a custom expression options member class to LanguageOptions, and modifies the clang expression evaluator to check the current runtime for those options. If those options are available on the runtime, they are passed to the clang compiler.
Committed for Luke Drummond.
Differential Revision: http://reviews.llvm.org/D15527
llvm-svn: 259644
A DWARF language vender extension for RenderScript was added to LLVM in r259348(http://reviews.llvm.org/D16409)
We should use this generated enum instead of the hardcoded value.
RenderScript is also based on C99 with some extensions, so we want to use ClangASTContext when RS is detected.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16766
llvm-svn: 259634
I don't understand how this worked before, but this fixes the recent test regressions on Windows in TestConsecutiveBreakpoints.py.
Differential Revision: http://reviews.llvm.org/D16825
llvm-svn: 259605
The file contained very similar 4 implementation of the same data
structure with a lot of duplicated code and some minor API differences.
This CL refactor the class to eliminate the duplicated codes and to
unify the APIs.
RangeMap.h also contained a class called AddressDataArray what have very
little added functionality over an std::vector and used only by
ObjectFileMacO The CL moves the class to ObjectFileMachO.cpp as it isn't
belongs into RangeMap.h and shouldn't be used in new places anyway
because of the little added functionality.
Differential revision: http://reviews.llvm.org/D16769
llvm-svn: 259538
The ARM instruction emulator had 2 bugs related to the handling of the
IT instruction causing an error in single stepping:
* We haven't initialized the IT mask from the CPSR so if the last
instruction of the IT block is a branch and the condition is false
then the emulator evaluated the branch what resulted in an incorrect
pc for the next instruction.
* The ITSTATE was advanced before the execution of each instruction. As
a result the emulator was using the condition of following instruction
in every case. The ITSTATE should be edvanced after the execution of
an instruction except after an IT instruction.
Differential revision: http://reviews.llvm.org/D16772
llvm-svn: 259509
Summary:
r259344 introduced a bug, where we fail to perform a single step, when the instruction we are
stepping onto contains a breakpoint which is not valid for this thread. This fixes the problem
and add a test case.
Reviewers: tberghammer, emaste
Subscribers: abhishek.aggarwal, lldb-commits, emaste
Differential Revision: http://reviews.llvm.org/D16767
llvm-svn: 259488
Summary:
- The patch solves Bug 23478 and Bug 19311. Resolving
Bug 23478 also resolves Bug 23039.
Correct ThreadStopInfo is set for Linux and FreeBSD
platforms.
- Summary:
When a trace event is reported, we need to check
whether the trace event lands at a breakpoint site.
If it lands at a breakpoint site then set the thread's
StopInfo with the reason 'breakpoint'. Else, set the reason
to be 'Trace'.
Change-Id: I0af9765e782fd74bc0cead41548486009f8abb87
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: jingham, emaste, lldb-commits, clayborg, ovyalov
Subscribers: emaste
Differential Revision: http://reviews.llvm.org/D16720
llvm-svn: 259344
Patch deletes the 'language renderscript module probe' command.
This command was present in the initial commit to help debug the plugin.
However we haven't used it recently and it's functionality is unclear, so can be removed entirely.
Also add back 'kernel coordinate' command, removed by accident in clang format patch r259056.
llvm-svn: 259181
The Visual Studio 2015 build was failing with the following error:
error C2440: 'initializing': cannot convert from 'const char [12]' to 'char *'
This should fix the problem by initializing a non const char array, instead of taking a pointer to const static data.
llvm-svn: 259042
Patch replaces the 'renderscript allocation list' command flag --refresh, with a new option --id <ID>.
This new option only prints the details of a single allocation with a given id, rather than printing all the allocations.
Functionality from the removed '--refresh' flag will be moved into its own command in a subsequent commit.
llvm-svn: 258800
This fixes the regression of several tests on Windows after rL258621.
The root problem is that ObjectFilePECOFF was not setting type information for the symbols, and the new CL rejects symbols without type information, breaking functionality like thread step-over.
The fix sets the type information for functions (and creates a TODO for other types).
Along the way, I fixed some typos and formatting that made the code I was debugging harder to understand.
In the long run, we should consider replacing most of ObjectFilePECOFF with the COFF parsing code from LLVM.
Differential Revision: http://reviews.llvm.org/D16563
llvm-svn: 258758
Pavel Labath