This introduces basic support for debugging OCaml binaries.
Use of the native compiler with DWARF emission support (see
https://github.com/ocaml/ocaml/pull/574) is required.
Available variables are considered as 64 bits unsigned integers,
their interpretation will be left to a OCaml-made debugging layer.
Differential revision: https://reviews.llvm.org/D22132
llvm-svn: 277443
Summary:
This adds the knowledge of the DW_CFA_GNU_args_size instruction to the eh_frame parsing code.
Right now it is ignored as I am unsure how is it supposed to be handled, but now we are at least
able to parse the rest of the FDE containing this instruction.
I also add a fix for a bug which was exposed by this instruction. Namely, a mismatched sequence
of remember/restore instructions in the input could cause us to pop an empty stack and crash. Now
we just log the error and ignore the offending instruction.
Reviewers: jasonmolenda
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D22266
llvm-svn: 275260
Bitfields were not correctly describing their offsets within the integer that they are contained within. If we had a bitfield like:
struct MyStruct {
uint32_t a:8;
uint32_t b:8;
};
ClangASTContext::GetChildCompilerTypeAtIndex would say that child a and b had the following values in their respective ValueObjectChild objects:
name byte-size bit-size bit-offset byte-offset-from-parent
==== ========= ======== ========== =======================
"a" 4 8 0 0
"b" 4 8 0 1
So if we had a "MyStruct" at address 0x1000, we would end up reading 4 bytes from 0x1000 for "a", and 4 bytes from 0x1001 for "b". The fix for this is to fix the "child_byte_offset" and "child_bitfield_bit_offset" values returned by ClangASTContext::GetChildCompilerTypeAtIndex() so that now the table looks like:
name byte-size bit-size bit-offset byte-offset-from-parent
==== ========= ======== ========== =======================
"a" 4 8 0 0
"b" 4 8 8 0
Then we don't run into a problem when reading data from a file's section info using "target variable" before running. It will also stop us from not being able to display a bitfield values if the bitfield is in the last bit of memory before an unmapped region. (Like if address 0x1004 was unmapped and unreadable in the example above, if we tried to read 4 bytes from 0x1001, the memory read would fail and we wouldn't be able to display "b").
<rdar://problem/27208225>
llvm-svn: 274701
may be in a function that is non-ABI conformant, and the eh_frame
instructions correctly describe how to unwind out of this function,
but the assembly parsing / arch default unwind plans would be
incorrect.
This is to address a problem that Ravitheja Addepally reported in
http://reviews.llvm.org/D21221 - I wanted to try handling the problem
with this approach which I think may be more generally helpful,
Ravitheja tested it and said it solves the problem on Linux/FreeBSD.
Ravi has a test case in http://reviews.llvm.org/D21221 that will
be committed separately.
Thanks for all the help on this one, Ravi.
llvm-svn: 274700
I changed "m_is_optimized" in lldb_private::CompileUnit over to be a lldb::LazyBool so that it can be set to eLazyBoolCalculate if it needs to be parsed later. With SymbolFileDWARFDebugMap, we don't actually open the DWARF in the .o files for each compile unit until later, and we can't tell if a compile unit is optimized ahead of time. So to avoid pulling in all .o right away just so we can answer the questions of "is this compile unit optimized" we defer it until a point where we will have the compile unit parsed.
<rdar://problem/26068360>
llvm-svn: 274585
We had support that assumed that thread local data for a variable could be determined solely from the module in which the variable exists. While this work for linux, it doesn't work for Apple OSs. The DWARF for thread local variables consists of location opcodes that do something like:
DW_OP_const8u (x)
DW_OP_form_tls_address
or
DW_OP_const8u (x)
DW_OP_GNU_push_tls_address
The "x" is allowed to be anything that is needed to determine the location of the variable. For Linux "x" is the offset within the TLS data for a given executable (ModuleSP in LLDB). For Apple OS variants, it is the file address of the data structure that contains a pthread key that can be used with pthread_getspecific() and the offset needed.
This fix passes the "x" along to the thread:
virtual lldb::addr_t
lldb_private::Thread::GetThreadLocalData(const lldb::ModuleSP module, lldb::addr_t tls_file_addr);
Then this is passed along to the DynamicLoader::GetThreadLocalData():
virtual lldb::addr_t
lldb_private::DynamicLoader::GetThreadLocalData(const lldb::ModuleSP module, const lldb::ThreadSP thread, lldb::addr_t tls_file_addr);
This allows each DynamicLoader plug-in do the right thing for the current OS.
The DynamicLoaderMacOSXDYLD was modified to be able to grab the pthread key from the data structure that is in memory and call "void *pthread_getspecific(pthread_key_t key)" to get the value of the thread local storage and it caches it per thread since it never changes.
I had to update the test case to access the thread local data before trying to print it as on Apple OS variants, thread locals are not available unless they have been accessed at least one by the current thread.
I also added a new lldb::ValueType named "eValueTypeVariableThreadLocal" so that we can ask SBValue objects for their ValueType and be able to tell when we have a thread local variable.
<rdar://problem/23308080>
llvm-svn: 274366
We were checking for integer types only before this. So I added the ability for CompilerType objects to check for integer and enum types.
Then I searched for places that were using the CompilerType::IsIntegerType(...) function. Many of these places also wanted to be checking for enumeration types as well, so I have fixed those places. These are in the ABI plug-ins where we are figuring out which arguments would go in where in regisers/stack when making a function call, or determining where the return value would live. The real fix for this is to use clang to compiler a CGFunctionInfo and then modify the code to be able to take the IR and a calling convention and have the backend answer the questions correctly for us so we don't need to create a really bad copy of the ABI in each plug-in, but that is beyond the scope of this bug fix.
Also added a test case to ensure this doesn't regress in the future.
llvm-svn: 273750
as an asynchronous unwind plan source.
Two small fixes to the compact unwind dumper tool for
armv7 encodings.
A change to DWARFCallFrameInfo to strip the 0th bit on
addresses in eh_frame sections when armv7. In the
clang generated examples I have, the 0th bit is set for
thumb functions and that's causing the unwinder to pick
the wrong function for eh_frame info.
llvm-svn: 271970
We have seen cases where we have been unable to find an argument type for a function, or we find one from another language, and then we try to create a function type by calling:
lldb_private::ClangASTContext::CreateFunctionType(clang::ASTContext*, lldb_private::CompilerType const&, lldb_private::CompilerType const*, unsigned int, bool, unsigned int)
This fix will ensure that all arguments to lldb_private::ClangASTContext::CreateFunctionType() are in order by checking:
- AST is valid
- if arguments are specified we have a valid argument array
- return type is valid
- return type is a clang type
- all argument types are valid
- all argument types are clang types
If any of these fail, we return an invalid CompilerType. If we don't return an invalid type, clang will crash anyway, and LLDB must not crash even in the presence of bad or missing debug info.
<rdar://problem/25172715>
llvm-svn: 270932
ClangASTContext::StartTagDeclarationDefinition(...) was starting definitions for any TagType instances that have TagDecl, but ClangASTContext::CompleteTagDeclarationDefinition(...) was getting the type to a CXXRecordDecl with:
clang::CXXRecordDecl *cxx_record_decl = qual_type->getAsCXXRecordDecl();
The problem is that getAsCXXRecordDecl() might dig a bit deeper into a type and dig out a different decl, which means we might call ClangASTContext::StartTagDeclarationDefinition(...), but it might not do anything, and then we might call ClangASTContext::CompleteTagDeclarationDefinition(...) and it might try to complete something that didn't have its definition started and this will crash.
This change fixes that, and also makes sure that starting a definition succeeds before any calls to ClangASTContext::CompleteTagDeclarationDefinition().
<rdar://problem/24091798>
llvm-svn: 270891
systems (ios, tvos, watchos). It's a simple format to use now that
I have i386/x86_64 supported already.
The unwind instructions are only valid at call sites -- that is,
when lldb is unwinding a frame in the middle of the stack. It
cannot be used for the currently executing frame; it has no information
about prologues/epilogues/etc.
<rdar://problem/12062336>
llvm-svn: 270658
m_decl_objects is problematic because it assumes that each VarDecl has a unique
variable associated with it. This is not the case in inline contexts.
Also the information in this map can be reconstructed very easily without
maintaining the map. The rest of the testsuite passes with this cange, and I've
added a testcase covering the inline contexts affected by this.
<rdar://problem/26278502>
llvm-svn: 270474
This is a pretty straightforward first pass over removing a number of uses of
Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there
are interfaces which take Mutex::Locker & to lock internal locks. This patch
cleans up most of the easy cases. The only non-trivial change is in
CommandObjectTarget.cpp where a Mutex::Locker was split into two.
llvm-svn: 269877
Summary:
The "file" variable in a LineEntry was mapped using target.source-map, except when stepping through inlined code. This patch adds a new variable to LineEntry, "original_file", that contains the original file from the debug info. "file" will continue to (possibly) be mapped.
Some code has been changed to use "original_file". This is code dealing with symbols. Code dealing with source files will still use "file". Reviewers, please confirm that these particular changes are correct.
Tests run on Ubuntu 12.04 show no regression.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20135
llvm-svn: 269250
should not be used for this module -- for use when an ObjectFile
knows that it does not have meaningful or accurate function start
addresses.
More commonly, it is not clear that function start addresses are
missing in a module. There are certain cases on Mac OS X where we
can tell that a Mach-O binary has been stripped of this essential
information, and the unwinder can end up emulating many megabytes
of instructions for a single "function" in the binary.
When a Mach-O binary is missing both an LC_FUNCTION_STARTS load
command (very unusual) and an eh_frame section, then we will assume
it has also been stripped of symbols and that instruction emulation
will not be useful on this module.
<rdar://problem/25988067>
llvm-svn: 268475
the field_begin that starts the copy or it won't do anything.
This causes failures, but only in complex apps, I haven't found
a reduced test case for this yet.
<rdar://problem/21951798>
llvm-svn: 268467
Also added a data formatter that presents them as structs if you use frame
variable to look at their contents. Now the blocks testcase works.
<rdar://problem/15984431>
llvm-svn: 268307
to use the default clang C/C++ expression parser when debugging
Rust programs. Ideally there would be a rust language plugin to
support their language natively, but until then this will get simple
variable display to work.
http://reviews.llvm.org/D19545
llvm-svn: 267667
Recommit modified version of r266311 including build bot regression fix.
This differs from the original r266311 by:
- Fixing Scalar::Promote to correctly zero- or sign-extend value depending
on signedness of the *source* type, not the target type.
- Omitting a few stand-alone fixes that were already committed separately.
llvm-svn: 266422
This implements a PDBASTParser and corresponding logic in
SymbolFilePDB to do type lookup by name. This is just a first
pass and leaves many aspects of type lookup unimplemented, and
just focuses on laying the framework. With this patch, you should
be able to lookup basic types by name from a PDB.
Full class definitions are not completed yet, we will instead
just return a forward declaration of the class.
Differential Revision: http://reviews.llvm.org/D18848
Reviewed by: Greg Clayton
llvm-svn: 266392
This patch fixes a bunch of issues that show up on big-endian systems:
- The gnu_libstdcpp.py script doesn't follow the way libstdc++ encodes
bit vectors: it should identify the enclosing *word* and then access
the appropriate bit within that word. Instead, the script simply
operates on bytes. This gives the same result on little-endian
systems, but not on big-endian.
- lldb_private::formatters::WCharSummaryProvider always assumes wchar_t
is UTF16, even though it could also be UTF8 or UTF32. This is mostly
not an issue on little-endian systems, but immediately fails on BE.
Fixed by checking the size of wchar_t like WCharStringSummaryProvider
already does.
- ClangASTContext::GetChildCompilerTypeAtIndex uses uint32_t to access
the virtual base offset stored in the vtable, even though the size
of this field matches the target pointer size according to the C++
ABI. Again, this is mostly not visible on LE, but fails on BE.
- Process::ReadStringFromMemory uses strncmp to search for a terminator
consisting of multiple zero bytes. This doesn't work since strncmp
will stop already at the first zero byte. Use memcmp instead.
Differential Revision: http://reviews.llvm.org/D18983
llvm-svn: 266313
The Scalar implementation and a few other places in LLDB directly
access the internal implementation of APInt values using the
getRawData method. Unfortunately, pretty much all of these places
do not handle big-endian systems correctly. While on little-endian
machines, the pointer returned by getRawData can simply be used as
a pointer to the integer value in its natural format, no matter
what size, this is not true on big-endian systems: getRawData
actually points to an array of type uint64_t, with the first element
of the array always containing the least-significant word of the
integer. This means that if the bitsize of that integer is smaller
than 64, we need to add an offset to the pointer returned by
getRawData in order to access the value in its natural type, and
if the bitsize is *larger* than 64, we actually have to swap the
constituent words before we can access the value in its natural type.
This patch fixes every incorrect use of getRawData in the code base.
For the most part, this is done by simply removing uses of getRawData
in the first place, and using other APInt member functions to operate
on the integer data.
This can be done in many member functions of Scalar itself, as well
as in Symbol/Type.h and in IRInterpreter::Interpret. For the latter,
I've had to add a Scalar::MakeUnsigned routine to parallel the existing
Scalar::MakeSigned, e.g. in order to implement an unsigned divide.
The Scalar::RawUInt, Scalar::RawULong, and Scalar::RawULongLong
were already unused and can be simply removed. I've also removed
the Scalar::GetRawBits64 function and its few users.
The one remaining user of getRawData in Scalar.cpp is GetBytes.
I've implemented all the cases described above to correctly
implement access to the underlying integer data on big-endian
systems. GetData now simply calls GetBytes instead of reimplementing
its contents.
Finally, two places in the clang interface code were also accessing
APInt.getRawData in order to actually construct a byte representation
of an integer. I've changed those to make use of a Scalar instead,
to avoid having to re-implement the logic there.
The patch also adds a couple of unit tests verifying correct operation
of the GetBytes routine as well as the conversion routines. Those tests
actually exposed more problems in the Scalar code: the SetValueFromData
routine didn't work correctly for 128- and 256-bit data types, and the
SChar routine should have an explicit "signed char" return type to work
correctly on platforms where char defaults to unsigned.
Differential Revision: http://reviews.llvm.org/D18981
llvm-svn: 266311
This fixes several test case failure on s390x caused by the fact that
on this platform, the default "char" type is unsigned.
- In ClangASTContext::GetBuiltinTypeForEncodingAndBitSize we should return
an explicit *signed* char type for encoding eEncodingSint and bit size 8,
instead of the default platform char type (which may be unsigned).
This fix matches existing code in ClangASTContext::GetIntTypeFromBitSize,
and fixes the TestClangASTContext.TestBuiltinTypeForEncodingAndBitSize
unit test case.
- The test/expression_command/char/TestExprsChar.py test case is known to
fail on platforms defaulting to unsigned char (pr23069), and just needs
to be xfailed on s390x like on arm.
- The test/functionalities/watchpoint/watchpoint_on_vectors/main.c test
case defines a vector of "char" and implicitly assumes to be signed.
Use an explicit "signed char" instead.
Differential Revision: http://reviews.llvm.org/D18979
llvm-svn: 266309
will not exceed the bounds of their Section. This is addressing a
problem where a file had a large space between two sections that
were not used by this module - the last symbol in the text section
had an enormous size because the distance between that and the first
symbol in the data section were used to compute the size.
http://reviews.llvm.org/D19004
<rdar://problem/25227945>
llvm-svn: 266165
TargetOptions is ambiguous due to a definition in LLVM and in clang. This was
exposed by SVN r265640. Update to fix the build against the newer revision.
llvm-svn: 265644
In doing so, two bugs were uncovered (and fixed). The first bug
is that ClangASTContext::RemoveFastQualifiers() was broken, and
was not removing fast qualifiers (or doing anything else for that
matter). The second bug is that UnifyAccessSpecifiers treated
AS_None asymmetrically, which is probably an edge case, but seems
like a bug nonetheless.
llvm-svn: 265200
Hubert Tong