Unnamed bitfields cause struct layout problems
Synthesize unnamed bitfields when required. Most compilers don't mention unnamed bitfields in the DWARF, so we need to create them to keep clang happy with the types we create from the DWARF. We currently can't do this for ObjC since the DW_AT_bit_offset value for any direct ivars of ObjC classes as the values for these attributes are bogus. A bug has been filed on Clang to fix this, and another bug has been filed on LLDB to make sure we fix the DWARF parser once the clang fix is in by looking the the DW_AT_producer in the compile unit attributes and finding the compiler version and only enabling it for newer versions of clang.
llvm-svn: 167424
- make sure to delet the .cer file on the desktop
- added section that describes what to do when you re-install a new OS where
you still have an old code signing certificate around.
llvm-svn: 167389
The operator== method is a synonym for IsExactMatch().
The essential difference between these two is that IsCompatibleMatch()
will say that armv7 and armv7s are compatible and return true.
IsExactMatch() will say that armv7 and armv7s are not a match.
An armv7s cpu can run either generic armv7 binaries or armv7s binaries
(the latter being tuned for it). When we're picking the slice of a
universal Mach-O file to load in an armv7s Target, we need to be able to
first look for an exact cpu subtype match (armv7s == armv7s) and failing
that, looking for a slice with a compatible architecture.
Update ObjectContainerUniversalMachO::GetObjectFile to prefer an exact
match of the cpu type, falling back to a compatible match if necessary.
<rdar://problem/12593515>
llvm-svn: 167365
the resolved version of the rhs FileSpec's directory name with the lhs FileSpec's directory name. We really meant to compare it
with the rhs FileSpec's directory name...
<rdar://problem/12438838>
llvm-svn: 167349
the runtime if we have complete debug information
for a class.
Also made the Objective-C language runtime return
NULL when asked for the complete debug information
(i.e., information from DWARF, not information from
the runtime) if that information isn't present. It
used to return a non-authoritative version, which
made it hard for clients to determine whether
complete debug information was available.
<rdar://problem/12608895>
llvm-svn: 167299
statements instead of a switch for the size of the floating
point types; some architectures sizeof double and sizeof long
double are the same and that's invalid in a switch.
Fix the LLDB_DISABLE_PYTHON ifdef block in FormatManager::LoadObjCFormatters
so it builds on arm again.
llvm-svn: 167263
LLDB now provides base class offsets (virtual and non virtual) to Clang's record layout. We previously were told this wasn't necessary, but it is when pragma pack gets involved.
llvm-svn: 167262
and silence the backtrace printout
In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly
instead of having the default behavior
llvm-svn: 167067
RegisterContextKDP_i386 was not correctly writing registers due to missing "virtual" keywords. Added the virtual keywords and made the functions pure virtual to ensure subclasses can't get away without implementing these functions.
llvm-svn: 167066
"~rc" via getpwnam() instead of doing tilde expansion and doing soft-link
dereferencing via realpath() - if we're pointing to a softlink, leave it
as-is.
<rdar://problem/12597698>
llvm-svn: 167052
The attached patch adds eValueTypeVector to lldb_private::Value. The nested struct Vector is patterned after RegisterValue::m_data.buffer. This change to Value allows ClangExpressionDeclMap::LookupDecl to return vector register data for consumption by InterpreterStackFrame::ResolveValue. Note that ResolveValue was tweaked slightly to allocate enough memory for vector registers.
An immediate result of this patch is that "expr $xmm0" generates the same results on Linux as on the Mac, which is good enough for TestRegisters.py. In addition, the log of m_memory.PrintData(data_region.m_base, data_region.m_extent) shows that the register content has been resolved successfully. On the other hand, the output is glaringly empty:
runCmd: expr $xmm0
output: (unsigned char __attribute__((ext_vector_type(16)))) $0 = {}
Expecting sub string: vector_type
Matched
llvm-svn: 167033
Greg Clayton