llvm-svn: 131372

for lldb-core.

llvm-svn: 131371

thread plan. In order to get the return value, you can call:

        void
        ThreadPlanCallFunction::RequestReturnValue (lldb::ValueSP &return_value_sp);
        
This registers a shared pointer to a return value that will get filled in if
everything goes well. After the thread plan is run the return value will be
extracted for you.

Added an ifdef to be able to switch between the LLVM MCJIT and the standand JIT.
We currently have the standard JIT selected because we have some work to do to
get the MCJIT fuctioning properly.

Added the ability to call functions with 6 argument in the x86_64 ABI.

Added the ability for GDBRemoteCommunicationClient to detect if the allocate
and deallocate memory packets are supported and to not call allocate memory 
("_M") or deallocate ("_m") if we find they aren't supported.

Modified the ProcessGDBRemote::DoAllocateMemory(...) and ProcessGDBRemote::DoDeallocateMemory(...) 
to be able to deal with the allocate and deallocate memory packets not being 
supported. If they are not supported, ProcessGDBRemote will switch to calling
"mmap" and "munmap" to allocate and deallocate memory instead using our 
trivial function call support.

Modified the "void ProcessGDBRemote::DidLaunchOrAttach()" to correctly ignore 
the qHostInfo triple information if any was specified in the target. Currently 
if the target only specifies an architecture when creating the target:

(lldb) target create --arch i386 a.out

Then the vendor, os and environemnt will be adopted by the target.

If the target was created with any triple that specifies more than the arch:

(lldb) target create --arch i386-unknown-unknown a.out

Then the target will maintain its triple and not adopt any new values. This
can be used to help force bare board debugging where the dynamic loader for
static files will get used and users can then use "target modules load ..."
to set addressses for any files that are desired.

Added back some convenience functions to the lldb_private::RegisterContext class
for writing registers with unsigned values. Also made all RegisterContext
constructors explicit to make sure we know when an integer is being converted
to a RegisterValue. 

llvm-svn: 131370

Also follow gcc in that arrays of elements with zero size are encoded as arrays with zero elements.

llvm-svn: 131369

that the destructor body is trivial and that all member variables also have either
trivial destructors or trivial destructor bodies, we don't need to initialize the
vtable pointers since no virtual member functions will be called on the destructor.

Fixes PR9181.

llvm-svn: 131368

llvm-svn: 131367

send if the receiver is null.  Normally it's not worthwhile to check this,
but avoiding the null-initialization is nice, and this also avoids nasty
problems where the null-initialization is visible within the call because
we use an aliased result buffer.  rdar://problem/9402992

llvm-svn: 131366

Go through and expand the members of bases into the encoding string (and encode the VTable as well).
Unlike gcc which expands virtual bases as many times as they appear in the
hierarchy, clang will only expand them once at the end, to reflect the actual layout.

Note that there doesn't seem to be a way to indicate in the encoding that
packing/alignment of members is different that normal, in which case
the encoding will be out-of-sync with the real layout.
If the runtime switches to just consider the size of types without
taking into account alignment, we could easily make padding explicit in the
encoding (e.g. using arrays of chars). The encoding strings would be
longer then though.

Also encode a flexible array member as array of 0 size, like gcc, not as a pointer.

llvm-svn: 131365

There are APIs, e.g. [NSValue valueWithBytes:objCType:], which use the encoding to find out
the size of an object pointed to by a pointer. Make things safer by making it illegal to @encode
incomplete types.

llvm-svn: 131364

llvm-svn: 131363

template<class U> 
struct X1 {
  template<class T> void f(T*);
  template<> void f(int*) { } 
};

Won't be so simple. I need to think more about it.

llvm-svn: 131362

llvm-svn: 131361

llvm-svn: 131360

llvm-svn: 131359

No need to pretend anymore that we do not update the LLVM-IR.

llvm-svn: 131358

llvm-svn: 131357

As we do not delete the SCoP, there is no need to remove it from the SCoP
detection.

llvm-svn: 131356

llvm-svn: 131355

The isl based routines implement a new interpretation of the Pluto algorithm
new interpretation. This patch requires a recent version of isl to be installed.

llvm-svn: 131354

If we only want to optimize a single function, we should extract this function
into a separate .ll file. This simplifies the code.

llvm-svn: 131353

Instead of deleting the old code, keep it on the side in an if-branch. It will
either be deleted by the dead code elimination or we can use it as fallback.

llvm-svn: 131352

llvm-svn: 131351

llvm-svn: 131350

Howard Hinnant. Thanks!

llvm-svn: 131349

llvm-svn: 131348

Necessary to parse MFC and MSVC standard lib code.

Example:
struct X {
  template<class T> void f(T) { }
  template<> void f(int) { } 
}

llvm-svn: 131347

llvm-svn: 131346

llvm-svn: 131345

llvm-svn: 131344

llvm-svn: 131343

Also, don't reject alias templates in all ElaboratedTypes: some ElaboratedTypes do not correspond to elaborated-type-specifiers.

llvm-svn: 131342

llvm-svn: 131341

llvm-svn: 131340

rdar://problem/9267970

Patch by Julien Lerouge!

llvm-svn: 131339

operators.

llvm-svn: 131338

llvm-svn: 131337

llvm-svn: 131336

out as "v-table" message sends and stop calling normal messages "legacy"
message sends.

Also, fix some comments to reveal the true state of affairs.

llvm-svn: 131335

llvm-svn: 131334

Breakpoint::Description with eDescriptionLevelBrief should just print the number of locations, printing the list of locations is pointless.

llvm-svn: 131333