addr_t
Address::GetCallableLoadAddress (Target *target) const;
This will resolve the load address in the Address object and optionally
decorate the address up to be able to be called. For all non ARM targets, this
just essentially returns the result of "Address::GetLoadAddress (target)". But
for ARM targets, it checks if the address is Thumb, and if so, it returns
an address with bit zero set to indicate a mode switch to Thumb. This is how
we need function pointers to be for return addresses and when resolving
function addresses for the JIT. It is also nice to centralize this in one spot
to avoid having multiple copies of this code.
llvm-svn: 131588
bool SectionLoadList::ResolveLoadAddress (addr_t load_addr, Address &so_addr) const;
Where if the address is in the last map entry, we need to look it up correctly.
My previous fix was incorrect where it looked in the first if there were
no addresses in the map that were > load_addr. Now we correctly look in the
last entry if our std::map::lower_bound search returns the end of the
collection.
llvm-svn: 131550
bool
Address::SetLoadAddress (lldb::addr_t load_addr, Target *target);
Added an == and != operator to RegisterValue.
Modified the ThreadPlanTracer to use RegisterValue objects to store the
register values when single stepping. Also modified the output to be a bit
less wide.
Fixed the ABIMacOSX_arm to not overwrite stuff on the stack. Also made the
trivial function call be able to set the ARM/Thumbness of the target
correctly, and also sets the return value ARM/Thumbness.
Fixed the encoding on the arm s0-s31 and d16 - d31 registers when the default
register set from a standard GDB server register sets.
llvm-svn: 131517
all register values. There is some junk that was appearing at the end
of the result the 'g' packet (read all register values). This function
was being called in:
bool
GDBRemoteRegisterContext::ReadAllRegisterValues (lldb::DataBufferSP &data_sp)
Then the packet data for the 'G' packet (write all registers) was being
placed into "data_sp" so the:
bool
GDBRemoteRegisterContext::WriteAllRegisterValues (const lldb::DataBufferSP &data_sp)
could restore it. In attempting to clean up the extra junk at the end of this
packet data, the packet was getting truncated.
llvm-svn: 131468
Modified ClangUserExpression and ClangUtilityFunction to display the actual
error (if one is available) that made the JIT fail instead of a canned
response.
Fixed the restoring of all register values when the 'G' packet doesn't work
to use the correct data.
llvm-svn: 131454
over when running JITed expressions. The allocated memory cache will cache
allocate memory a page at a time for each permission combination and divvy up
the memory and hand it out in 16 byte increments.
llvm-svn: 131453
give the reason for the interrupt. Also make sure it we don't want to unwind from the evaluation
we print something if it is interrupted.
llvm-svn: 131448
Prior to this fix we would often call SendPacketAndWaitForResponse() which
returns the number of bytes in the response. The UNSUPPORTED response in the
GDB remote protocol is zero bytes and we were checking for it inside an if
statement:
if (SendPacketAndWaitForResponse(...))
{
if (response.IsUnsupportedResponse())
{
// UNSUPPORTED...
// This will never happen...
}
}
We now handle is properly as:
if (SendPacketAndWaitForResponse(...))
{
}
else
{
// UNSUPPORTED...
}
llvm-svn: 131393
the appropriate registers for arm and x86_64. The register names for the
arguments that are the size of a pointer or less are all named "arg1", "arg2",
etc. This allows you to read these registers by name:
(lldb) register read arg1 arg2 arg3
...
You can also now specify you want to see alternate register names when executing
the read register command:
(lldb) register read --alternate
(lldb) register read -A
llvm-svn: 131376
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
solve the build break due to the lack of this method.
It also propose a solution to the API changes in RegisterContext.
I upgraded also the the python version in the makefile. My linux
installation has python2.7 and AFAIK also the latest ubuntu
has this version of python so maybe is worth upgrading.
Patch by Marco Minutoli <mminutoli@gmail.com>
[Note: I had to hand merge in the diffs since patch thinks it is a corrupt patch.]
llvm-svn: 131313
as non-const in the debug information, added a fallback
to GetFunctionAddress, adding the const qualifier after
the fact and searching again.
llvm-svn: 131299
representing variables whose type must be inferred
from the way they are used. Functions without debug
information now return UnknownAnyTy and must be cast.
Variables with no debug information are not yet using
UnknownAnyTy; instead they are assumed to be void*.
Support for variables of unknown type is coming (and,
in fact, some relevant support functions are included
in this commit) but will take a bit of extra effort.
The testsuite has also been updated to reflect the new
requirement that the result of printf be cast, i.e.
expr (int) printf("Hello world!")
llvm-svn: 131263
of the current instruction plus 8. And for Triple::thumb, it is plus 4.
rdar://problem/9170971
lldb disassembly's symbol information not correct (off by 2?)
llvm-svn: 131256
pointers:
virtual bool
PrepareTrivialCall (Thread &thread,
lldb::addr_t sp,
lldb::addr_t functionAddress,
lldb::addr_t returnAddress,
lldb::addr_t *arg1_ptr,
lldb::addr_t *arg2_ptr,
lldb::addr_t *arg3_ptr) const = 0;
Prior to this it was:
virtual bool
PrepareTrivialCall (Thread &thread,
lldb::addr_t sp,
lldb::addr_t functionAddress,
lldb::addr_t returnAddress,
lldb::addr_t arg,
lldb::addr_t *this_arg,
lldb::addr_t *cmd_arg) const = 0;
This was because the function that called this slowly added more features to
be able to call a C++ member function that might have a "this" pointer, and
then later added "self + cmd" support for objective C. Cleaning this code up
and the code that calls it makes it easier to implement the functions for
new targets.
The MacOSX_arm::PrepareTrivialCall() is now filled in and ready for testing.
llvm-svn: 131221
respective ABI plugins as they were plug-ins that supplied ABI specfic info.
Also hookep up the UnwindAssemblyInstEmulation so that it can generate the
unwind plans for ARM.
Changed the way ABI plug-ins are handed out when you get an instance from
the plug-in manager. They used to return pointers that would be mananged
individually by each client that requested them, but now they are handed out
as shared pointers since there is no state in the ABI objects, they can be
shared.
llvm-svn: 131193
looked up. Queries for global types were made
too specific -- including the current module
and compile unit in the query was limiting the
search when we wanted a truly global search.
llvm-svn: 131145
treated as being permanently resident in target
memory. In fact, since the expression's stack frame
is deleted and potentially re-used after the
expression completes, the variables need to be treated
as being freeze-dried.
llvm-svn: 131104
into some cleanup I have been wanting to do when reading/writing registers.
Previously all RegisterContext subclasses would need to implement:
virtual bool
ReadRegisterBytes (uint32_t reg, DataExtractor &data);
virtual bool
WriteRegisterBytes (uint32_t reg, DataExtractor &data, uint32_t data_offset = 0);
There is now a new class specifically designed to hold register values:
lldb_private::RegisterValue
The new register context calls that subclasses must implement are:
virtual bool
ReadRegister (const RegisterInfo *reg_info, RegisterValue ®_value) = 0;
virtual bool
WriteRegister (const RegisterInfo *reg_info, const RegisterValue ®_value) = 0;
The RegisterValue class must be big enough to handle any register value. The
class contains an enumeration for the value type, and then a union for the
data value. Any integer/float values are stored directly in an appropriate
host integer/float. Anything bigger is stored in a byte buffer that has a length
and byte order. The RegisterValue class also knows how to copy register value
bytes into in a buffer with a specified byte order which can be used to write
the register value down into memory, and this does the right thing when not
all bytes from the register values are needed (getting a uint8 from a uint32
register value..).
All RegiterContext and other sources have been switched over to using the new
regiter value class.
llvm-svn: 131096
a new "QLaunchArch:<arch-name>" where <arch-name> is the architecture name.
This allows us to remotely launch a debugserver and then set the architecture
for the binary we will launch.
llvm-svn: 131064
Johnny Chen