Summary:
This commit avoids the Platform instance when spawning or attaching to a process in lldb-server.
Instead, I have the server call a (static) method of NativeProcessProtocol directly. The reason
for this is that I believe that NativeProcessProtocol should be decoupled from the Platform
(after all, it always knows which platform it is running on, unlike the rest of lldb).
Additionally, the kind of platform actions a NativeProcessProtocol instance is likely to differ
greatly from the platform actions of the lldb client, so I think the separation makes sense.
After this, the only dependency NativeProcessLinux has on PlatformLinux is the ResolveExecutable
method, which needs additional refactoring.
Reviewers: ovyalov, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10996
llvm-svn: 241672
The fix is to emit cleanup for arrays of memcpy-able objects in struct if an exception is thrown later during copy-construction.
Differential Revision: http://reviews.llvm.org/D10989
llvm-svn: 241670
This reverts commit r239846 and r239879. They caused clang's
-fms-extensions behavior to incorrectly parse lambdas and includes a
testcase to ensure we don't regress again.
This issue was found in PR24027.
llvm-svn: 241668
We didn't correctly process the case where a base class is classified as
MEMORY. This would cause us to trip over an assertion.
This fixes PR24020.
Differential Revision: http://reviews.llvm.org/D10907
llvm-svn: 241667
We forgot to run postMerge after decided that the union had to be
classified as MEMORY. This left us with Lo == MEMORY and Hi == SSEUp
which is an invalid combination.
This fixes PR24021.
Differential Revision: http://reviews.llvm.org/D10908
llvm-svn: 241666
instantiation, use the set of modules visible from the template definition, not
from whichever declaration the specialization was instantiated from.
llvm-svn: 241662
option that works with all object container formats.
Now that clang modules/PCH are object containers this option is useful to
to construct pipes like
llvm-objdump -raw-clang-ast foo.pcm | llvm-bcanalyzer -
to inspect the AST contents in a PCH container.
Will be tested via clang.
Belatedly addresses review feedback for r233390.
llvm-svn: 241659
Summary:
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.
Reviewers: echristo
Subscribers: llvm-commits, rafael, yaron.keren
Differential Revision: http://reviews.llvm.org/D11017
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 241655
Summary:
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.
Reviewers: echristo
Subscribers: yaron.keren, rafael, llvm-commits
Differential Revision: http://reviews.llvm.org/D11009
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 241654
results if the -Q option is not provided. Also took out the quietly
option from AddInitialCommand, we don't use that to set this option,
we use the override set by the -Q option.
<rdar://problem/21232087>
llvm-svn: 241652
We don't need to do the fancy dance with checking whether the iterator
represents a #define -- in fact, that's the wrong thing to do. The thing to do
is check whether the highest-priority module that did something to the module
#defined or #undefd it. If it #defined it, then the MacroInfo* will be non-NULL
and we're good to go.
llvm-svn: 241651
This can be in the cpp file rather than the header file, so moving
it there.
Summary: Move ProcessKDP's StringExtractor include.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11018
llvm-svn: 241649
The incoming EBP value points to the end of a local stack allocation, so
we can use that to restore ESI, the base pointer. Once we do that, we
can use local stack allocations. If we know we need stack realignment,
spill the original frame pointer in the prologue and reload it after
restoring ESI.
llvm-svn: 241648
Summary:
This change is part of a series of commits dedicated to have a single
DataLayout during compilation by using always the one owned by the
module.
Reviewers: echristo
Subscribers: llvm-commits, rafael, yaron.keren
Differential Revision: http://reviews.llvm.org/D11010
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 241646
This commit adopts the 'ModuleSlotTracker' class, which was surfaced in r240842,
to print the global address operands. This change ensures that the slot tracker
won't have to be recreated every time a global address operand is printed,
making the MIR printing more efficient.
llvm-svn: 241645
Tim Northover has told me that they can occur when the compiler cleverly
constructs constants - as demonstrated in the test case.
rdar://21703486
llvm-svn: 241641
Summary:
Initially, these intrinsics seemed like part of a family of "frame"
related intrinsics, but now I think that's more confusing than helpful.
Initially, the LangRef specified that this would create a new kind of
allocation that would be allocated at a fixed offset from the frame
pointer (EBP/RBP). We ended up dropping that design, and leaving the
stack frame layout alone.
These intrinsics are really about sharing local stack allocations, not
frame pointers. I intend to go further and add an `llvm.localaddress()`
intrinsic that returns whatever register (EBP, ESI, ESP, RBX) is being
used to address locals, which should not be confused with the frame
pointer.
Naming suggestions at this point are welcome, I'm happy to re-run sed.
Reviewers: majnemer, nicholas
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11011
llvm-svn: 241633
Pavel Labath