Replace adhoc inline implementation of llvm::array_lengthof in favour of the
implementation in LLVM. This is simply a cleanup change, no functional change
intended.
llvm-svn: 211868
This is a mechanical change addressing the various sign comparison warnings that
are identified by both clang and gcc. This helps cleanup some of the warning
spew that occurs during builds.
llvm-svn: 205390
read during materialization. First of all, report
if we can't read the data for some reason. Second,
consult the ValueObject's error and report that if
there's some problem.
<rdar://problem/16074201>
llvm-svn: 202552
llvm::ArrayRef of arguments rather than taking
a fixed number of possibly-NULL pointers to
arguments.
Also changed ClangFunction::GetThreadPlanToCallFunction
to take the address of the argument struct by value
instead of by reference, since it doesn't actually
modify the value passed into it.
llvm-svn: 194232
Instead of looking up registers by name, we use the generic ID when we can.
Also added code that creates an extra frame when running expressions by pushing the current PC and FP and then hooking up the FP backchain. This code is "#if 0" out for now until we can pair it with unwinder fixes.
llvm-svn: 194035
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that it
wasn't working out like I intended. Instead I'll try sticking with
the single StackFrame class -- there's too much code duplication to
make a more complicated class hierarchy sensible I think.
llvm-svn: 193983
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends are
nearly identical to StackFrame's old methods.
Update all callers to use Frame*/Frame& instead of pointers to
StackFrames.
This is almost entirely a mechanical change that touches a lot of
the code base so I'm committing it alone. No new functionality is
added with this patch, no new subclasses of Frame exist yet.
I'll probably need to tweak some of the separation, possibly moving
some of StackFrame's methods up in to Frame, but this is a good
starting point.
<rdar://problem/15314068>
llvm-svn: 193907
been down for months and is likely no longer supported. This was
the most stable-looking link I could find for the current (0.99.6)
version of the ABI doc.
llvm-svn: 187087
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.
This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.
llvm-svn: 186130
<rdar://problem/13594769>
Main changes in this patch include:
- cleanup plug-in interface and use ConstStrings for plug-in names
- Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp
- Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging
The plug-in interface changes:
Modified the lldb_private::PluginInterface class that all plug-ins inherit from:
Changed:
virtual const char * GetPluginName() = 0;
To:
virtual ConstString GetPluginName() = 0;
Removed:
virtual const char * GetShortPluginName() = 0;
- Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names.
- Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc.
llvm-svn: 181631
- Adds unique enums for ymm registers to the ABI and the POSIX register context.
- Reworks the register context data structures to support a union of FXSAVE and XSAVE
--- Allows the same code base to deal with the FPU independent of the availability of AVX.
- Determine if AVX is supported by attempting to read XSAVE using ptrace.
--- Support an extended register set for avx registers if available.
- Provide a mechanism to assemble/parse register halves into a single ymm buffer for use with RegisterValue.
--- Reworked Read/WriteRegister routines to read/write/parse ymm registers.
Adds tests for ymm register write with read-back, and expressions involving ymm registers.
- Tests vary depending on the availability of an avx register set.
Thanks to Daniel and Matt for their reviews.
llvm-svn: 180572
Now we can:
1 - see the return value for functions that return types that use the "ext_vector_size"
2 - dump values that use the vector attributes ("expr $ymm0")
3 - modified the DWARF parser to correctly parse GNU vector types from the DWARF by turning them into clang::Type::ExtVector types instead of just standard arrays
llvm-svn: 178924
LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.
All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.
llvm-svn: 178191
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.
So I defined a new "lldb::offset_t" which should be used for all file offsets.
After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.
Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.
llvm-svn: 173463
Full UnwindPlan is trying to do an impossible unwind; in that case
invalidate the Full UnwindPlan and replace it with the architecture
default unwind plan.
This is a scenario that happens occasionally with arm unwinds in
particular; the instruction analysis based full unwindplan can
mis-parse the functions and the stack walk stops prematurely. Now
we can do a simpleminded frame-chain walk to find the caller frame
and continue the unwind. It's not ideal but given the complicated
nature of analyzing the arm functions, and the lack of eh_frame
information on iOS, it is a distinct improvement and fixes some
long-standing problems with the unwinder on that platform.
This is fixing <rdar://problem/12091421>. I may re-use this
invalidate feature in the future if I can identify other cases where
the full unwindplan's unwind information is clearly incorrect.
This checkin also includes some cleanup for the volatile register
definition in the arm ABI plugin for <rdar://problem/10652166>
although work remains to be done for that bug.
llvm-svn: 166757
Added new API to lldb::SBTypeMember for bitfields:
bool SBTypeMember::IsBitfield();
uint32_t SBTypeMember::GetBitfieldSizeInBits();
Also added new properties for easy access. Now SBTypeMember objects in python have a "fields" property for all type fields, "bases" for all direct bases, "vbases" for all virtual base classes and "members" for a combo of all three organized by bit offset. They all return a python list() of SBTypeMember objects. Usage:
(lldb) script
>>> t = lldb.target.FindFirstType("my_type")
>>> for field in t.fields:
... print field
>>> for vbase in t.vbases:
... print vbase
>>> for base in t.bases:
... print base
>>> for member in t.members:
... print member
Also added new "is_bitfield" property to the SBTypeMember objects that will return the result of SBTypeMember::IsBitfield(), and "bitfield_bit_size" which will return the result of SBTypeMember::GetBitfieldSizeInBits();
I also fixed "SBTypeMember::GetOffsetInBytes()" to return the correct byte offset.
llvm-svn: 161091
a shared pointer to ease some memory management issues with a patch
I'm working on.
The main complication with using SPs for these objects is that most
methods that build up an UnwindPlan will construct a Row to a given
instruction point in a function, then add additional regsaves in
the next instruction point to that row and push it again. A little
care is needed to not mutate the previous instruction point's Row
once these are switched to being held behing shared pointers.
llvm-svn: 160214
Initial step -- infrastructure change -- to fix the bug. Change the RegisterInfo data structure
to contain two additional fields (uint32_t *value_rges and uint32_t *invalidate_regs) to facilitate
architectures which have register mapping.
Update all existing RegsiterInfo arrays to have two extra NULL's (the additional fields) in each row,
GDBRemoteRegisterContext.cpp is modified to add d0-d15 and q0-q15 register info entries which take
advantage of the value_regs field to specify the containment relationship:
d0 -> (s0, s1)
...
d15 -> (s30, s31)
q0 -> (d0, d1)
...
q15 -> (d30, d31)
llvm-svn: 151686
objects for the backlink to the lldb_private::Process. The issues we were
running into before was someone was holding onto a shared pointer to a
lldb_private::Thread for too long, and the lldb_private::Process parent object
would get destroyed and the lldb_private::Thread had a "Process &m_process"
member which would just treat whatever memory that used to be a Process as a
valid Process. This was mostly happening for lldb_private::StackFrame objects
that had a member like "Thread &m_thread". So this completes the internal
strong/weak changes.
Documented the ExecutionContext and ExecutionContextRef classes so that our
LLDB developers can understand when and where to use ExecutionContext and
ExecutionContextRef objects.
llvm-svn: 151009
Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject
which is much more convenient.
Return the "return value object" as a persistent variable if requested.
llvm-svn: 147157
UnwindPlan for unwinding from the first instruction of an otherwise
unknown function call (GetUnwindPlanArchitectureDefaultAtFunctionEntry()).
Update RegisterContextLLDB::GetFullUnwindPlanForFrame() to detect the
case of a frame 0 at address 0x0 which indicates that we jumped through
a NULL function pointer. Use the ABI's FunctionEntryUnwindPlan to
find the caller frame.
These changes make it so lldb can identify the calling frame correctly
in code like
int main ()
{
void (*f)(void) = 0;
f();
}
llvm-svn: 139760
plug-ins are add on plug-ins for the lldb_private::Process class that can add
thread contexts that are read from memory. It is common in kernels to have
a lot of threads that are not currently executing on any cores (JTAG debugging
also follows this sort of thing) and are context switched out whose state is
stored in memory data structures. Clients can now subclass the OperatingSystem
plug-ins and then make sure their Create functions correcltly only enable
themselves when the right binary/target triple are being debugged. The
operating system plug-ins get a chance to attach themselves to processes just
after launching or attaching and are given a lldb_private::Process object
pointer which can be inspected to see if the main executable, target triple,
or any shared libraries match a case where the OS plug-in should be used.
Currently the OS plug-ins can create new threads, define the register contexts
for these threads (which can all be different if desired), and populate and
manage the thread info (stop reason, registers in the register context) as
the debug session goes on.
llvm-svn: 138228
of duplicated code from appearing all over LLDB:
lldb::addr_t
Process::ReadPointerFromMemory (lldb::addr_t vm_addr, Error &error);
bool
Process::WritePointerToMemory (lldb::addr_t vm_addr, lldb::addr_t ptr_value, Error &error);
size_t
Process::ReadScalarIntegerFromMemory (lldb::addr_t addr, uint32_t byte_size, bool is_signed, Scalar &scalar, Error &error);
size_t
Process::WriteScalarToMemory (lldb::addr_t vm_addr, const Scalar &scalar, uint32_t size, Error &error);
in lldb_private::Process the following functions were renamed:
From:
uint64_t
Process::ReadUnsignedInteger (lldb::addr_t load_addr,
size_t byte_size,
Error &error);
To:
uint64_t
Process::ReadUnsignedIntegerFromMemory (lldb::addr_t load_addr,
size_t byte_size,
uint64_t fail_value,
Error &error);
Cleaned up a lot of code that was manually doing what the above functions do
to use the functions listed above.
Added the ability to get a scalar value as a buffer that can be written down
to a process (byte swapping the Scalar value if needed):
uint32_t
Scalar::GetAsMemoryData (void *dst,
uint32_t dst_len,
lldb::ByteOrder dst_byte_order,
Error &error) const;
The "dst_len" can be smaller that the size of the scalar and the least
significant bytes will be written. "dst_len" can also be larger and the
most significant bytes will be padded with zeroes.
Centralized the code that adds or removes address bits for callable and opcode
addresses into lldb_private::Target:
lldb::addr_t
Target::GetCallableLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const;
lldb::addr_t
Target::GetOpcodeLoadAddress (lldb::addr_t load_addr, AddressClass addr_class) const;
All necessary lldb_private::Address functions now use the target versions so
changes should only need to happen in one place if anything needs updating.
Fixed up a lot of places that were calling :
addr_t
Address::GetLoadAddress(Target*);
to call the Address::GetCallableLoadAddress() or Address::GetOpcodeLoadAddress()
as needed. There were many places in the breakpoint code where things could
go wrong for ARM if these weren't used.
llvm-svn: 131878
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
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
an interface to a local or remote debugging platform. By default each host OS
that supports LLDB should be registering a "default" platform that will be
used unless a new platform is selected. Platforms are responsible for things
such as:
- getting process information by name or by processs ID
- finding platform files. This is useful for remote debugging where there is
an SDK with files that might already or need to be cached for debug access.
- getting a list of platform supported architectures in the exact order they
should be selected. This helps the native x86 platform on MacOSX select the
correct x86_64/i386 slice from universal binaries.
- Connect to remote platforms for remote debugging
- Resolving an executable including finding an executable inside platform
specific bundles (macosx uses .app bundles that contain files) and also
selecting the appropriate slice of universal files for a given platform.
So by default there is always a local platform, but remote platforms can be
connected to. I will soon be adding a new "platform" command that will support
the following commands:
(lldb) platform connect --name machine1 macosx connect://host:port
Connected to "machine1" platform.
(lldb) platform disconnect macosx
This allows LLDB to be well setup to do remote debugging and also once
connected process listing and finding for things like:
(lldb) process attach --name x<TAB>
The currently selected platform plug-in can now auto complete any available
processes that start with "x". The responsibilities for the platform plug-in
will soon grow and expand.
llvm-svn: 127286
now, in addition to cpu type/subtype and architecture flavor, contains:
- byte order (big endian, little endian)
- address size in bytes
- llvm::Triple for true target triple support and for more powerful plug-in
selection.
llvm-svn: 125602
an issue with the way the UnwindLLDB was handing out RegisterContexts: it
was making shared pointers to register contexts and then handing out just
the pointers (which would get put into shared pointers in the thread and
stack frame classes) and cause double free issues. MallocScribble helped to
find these issues after I did some other cleanup. To help avoid any
RegisterContext issue in the future, all code that deals with them now
returns shared pointers to the register contexts so we don't end up with
multiple deletions. Also now that the RegisterContext class doesn't require
a stack frame, we patched a memory leak where a StackFrame object was being
created and leaked.
Made the RegisterContext class not have a pointer to a StackFrame object as
one register context class can be used for N inlined stack frames so there is
not a 1 - 1 mapping. Updates the ExecutionContextScope part of the
RegisterContext class to never return a stack frame to indicate this when it
is asked to recreate the execution context. Now register contexts point to the
concrete frame using a concrete frame index. Concrete frames are all of the
frames that are actually formed on the stack of a thread. These concrete frames
can be turned into one or more user visible frames due to inlining. Each
inlined stack frame has the exact same register context (shared via shared
pointers) as any parent inlined stack frames all the way up to the concrete
frame itself.
So now the stack frames and the register contexts should behave much better.
llvm-svn: 122976
the code to pass the _cmd pointer has been improved, and _cmd
is now set to the value of _cmd for the current context, as
opposed to being simply NULL.
llvm-svn: 121739
access to the members of the Objective-C self object.
The approach we take is to generate the method as a
@category on top of the self object, and to pass the
"self" pointer to it. (_cmd is currently NULL.)
Most changes are in ClangExpressionDeclMap, but the
change that adds support to the ABIs to pass _cmd
touches a fair amount of code.
llvm-svn: 121722
Enrico Granata