Commit Graph

652 Commits

Author SHA1 Message Date
Saleem Abdulrasool 16ff860469 remove use of Mutex in favour of std::{,recursive_}mutex
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
2016-05-18 01:59:10 +00:00
Zachary Turner 4fd6a96008 Clean up test results on Windows.
Remove XFAIL from some tests that now pass.
Add XFAIL to some tests that now fail.
Fix a crasher where a null pointer check isn't guarded.
Properly handle all types of errors in SymbolFilePDB.

llvm-svn: 269454
2016-05-13 18:26:30 +00:00
Pavel Labath b8d8c62b34 Fix assertion in SymbolFilePDB
llvm::Error requires all errors to be handled. Simply checking the whether there was an error is
not enough, you have to actuall call handle(All)Errors, in case there was an error.

llvm-svn: 268906
2016-05-09 11:07:43 +00:00
Zachary Turner 50c58c0d01 Fix LLDB after removal of PDB_ErrorCode
llvm-svn: 268802
2016-05-06 21:35:47 +00:00
Tamas Berghammer 2ff833060c Add support for displaying Java array types on Andorid
Differential revision: http://reviews.llvm.org/D19540

llvm-svn: 268622
2016-05-05 11:18:21 +00:00
Pavel Labath b9436bd493 Fix DW_AT_specification handling in DWO files
Summary:
We were trying to get a DWARFDIE from a CompileUnit belonging to a DWO file. However, this
function does not understand the die encoding used by the DWO files. Instead use GetDIE on the
SymbolFileDWARF, which is overriden in DWO to do the right thing.

Reviewers: clayborg, tberghammer

Subscribers: lldb-commits, ovyalov

Differential Revision: http://reviews.llvm.org/D19927

llvm-svn: 268615
2016-05-05 08:21:44 +00:00
Zachary Turner 54fd7ff6db Update for llvm change to add pdb namespace.
r268544 moves all PDB reading code into a pdb namespace,
so LLDB needs to be updated to take this into account.

llvm-svn: 268545
2016-05-04 20:33:53 +00:00
Bryan Chan c4abaefadb Fix a SIGSEGV caused by dereferencing a pointer without a null check
llvm-svn: 268520
2016-05-04 17:24:31 +00:00
Sean Callanan c530ba98a9 Import block pointers from DWARF as Clang block pointers, not as structs.
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
2016-05-02 21:15:31 +00:00
Greg Clayton d49a8f9b54 Watch out for compilers that generate bad bitfield info. If the bit size of a bitfield member doesn't lie within the bit bounds of the type itself, just leave it out so we don't get clang asserting and killing our IDE when it gets unhappy with the information.
https://llvm.org/bugs/show_bug.cgi?id=27515
<rdar://problem/21082998>

llvm-svn: 268110
2016-04-29 21:26:46 +00:00
Greg Clayton 909b277845 Make sure LLDB can deal with forward declarations to enums without crashing or asserting.
<rdar://problem/23776428> 

llvm-svn: 268098
2016-04-29 20:48:39 +00:00
Greg Clayton 07c8c4475f Make sure that the following SymbolFileDWARF functions can handle getting a lldb::user_id_t for another SymbolFileDWARF:
CompilerDecl
SymbolFileDWARF::GetDeclForUID (lldb::user_id_t type_uid);

CompilerDeclContext
SymbolFileDWARF::GetDeclContextForUID (lldb::user_id_t type_uid)

CompilerDeclContext
SymbolFileDWARF::GetDeclContextContainingUID (lldb::user_id_t type_uid)

Type*
SymbolFileDWARF::ResolveTypeUID (lldb::user_id_t type_uid)

<rdar://problem/25592223>

llvm-svn: 267494
2016-04-25 23:39:19 +00:00
Greg Clayton cae0855a62 DWARF layout for bitfields is wrong when the bit offset is negative.
Some older versions of clang emitted bit offsets that were negative and these bitfields would have their bitfield-ness stripped off and it would cause a clang assertion in clang assertions were enabled. I updated the bitfield C test to make sure we don't regress.

<rdar://problem/21082998> 

llvm-svn: 267248
2016-04-22 23:14:35 +00:00
Greg Clayton f443135b8c Fixed in issue with ObjectFileMachO where it would add empty sections to the section list that was used to try and cap symbols to the max address of the section in which it is contained. The empty sections would make cap the symbols and make their sizes zero. Also fixed a few other things that could cause problems in the SymbolFileDWARFDebugMap when zero sized symbols were found and used to make OSO range map entries.
<rdar://problem/25886773>

llvm-svn: 267237
2016-04-22 22:35:08 +00:00
Greg Clayton 0257603c2d When making an array or stuct/union/class elements, make sure the type is complete. If the type isn't complete, complete the type so that clang won't assert and kill your program. Since the DWARF assists in doing layout, it won't show the array or struct/unions/class elements correctly, but it will stop you from crashing if you have a struct/union/class that contains one of these arrays.
<rdar://problem/25057391>

llvm-svn: 266922
2016-04-20 21:47:56 +00:00
Zachary Turner 42dff79068 Initial support for reading type information from PDBs.
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
2016-04-15 00:21:26 +00:00
Greg Clayton 58a15d5a23 Fixed an issue where if we have DWARF in an executable that has multiple languages where these languages use different type systems, you can end up trying to find the actualy definition for a forward declaration for a type, you will call:
TypeSP SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext (const DWARFDeclContext &dwarf_decl_ctx);

The problem was we might be looking for a type "Foo", and find one from another langauge. Then the DWARFASTParserClang would try to make an AST type using a CompilerType that might return an empty. 

This fix makes sure that when we create a DWARFDeclContext from a DWARFDIE that the DWARFDeclContext we set the language of the DIE. Then when we go to find matches for DWARFDeclContext, we end up with bunch of DIEs. We check each DWARFDIE that we found by asking it for its language and making sure the language is compatible with the type system that we want to use. This keeps us from using the wrong types to resolve forward declarations.

<rdar://problem/25276165>

llvm-svn: 265196
2016-04-01 22:57:22 +00:00
Pavel Labath a5d09f64a1 Change a recently added assert into lldbassert
llvm-svn: 265124
2016-04-01 09:57:30 +00:00
Pavel Labath 63168e08bd Fix DWO breakage in r264909
Summary:
In case of Dwo, DIERef stores a compile unit offset in the main object file, and not in the dwo.
The implementation of SymbolFileDWARFDwo::GetDIE inherited from SymbolFileDWARF tried to lookup
the compilation unit in the DWO based on the main object file offset (and failed). I change the
implementation to verify the DIERef indeed references compile unit belonging to this dwo and then
lookup the die based on the die offset alone.

Includes a couple of fixes for mismatched struct/class tags.

Reviewers: tberghammer, clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D18646

llvm-svn: 265011
2016-03-31 13:30:04 +00:00
Greg Clayton 2f869fe9d2 When support for DWO files was added, there were two ways to pass lldb::user_id_t out to the rest of LLDB:
1 - DWARF in .o files with debug map in executable: we would place the compile unit index in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset
2 - DWO: we would place the compile unit offset in the upper 32 bits of the 64 bit value and the lower 32 bits would be the DIE offset

There was a mixing and matching of this and it wasn't done consistently.

Major changes include:

The DIERef constructor that takes a lldb::user_id_t now requires a SymbolFileDWARF:

DIERef(lldb::user_id_t uid, SymbolFileDWARF *dwarf)

It is needed so that it can be decoded correctly. If it is DWARF in .o files with debug map in executable, then we get the right compile unit from the SymbolFileDWARFDebugMap, otherwise, we use the compile unit offset and DIE offset for DWO or normal DWARF.

The function:

lldb::user_id_t DIERef::GetUID() const;

Now becomes

lldb::user_id_t DIERef::GetUID(SymbolFileDWARF *dwarf) const;

Again, we need the DWARF file to encode it correctly.

This removes the need for "lldb::user_id_t SymbolFileDWARF::MakeUserID() const" and for bool SymbolFileDWARF::UserIDMatches (lldb::user_id_t uid) const". There were also many places were doing things inneficiently like:

1 - encode a dw_offset_t into a lldb::user_id_t
2 - call the public SymbolFile interface to resolve types using the lldb::user_id_t
3 - This would then decode the lldb::user_id_t into a DIERef, and then try to find that type.

There are many places that are now doing this more efficiently by storing DW_AT_type form values as DWARFFormValue objects and then making a DIERef from them and directly calling the underlying function to resolve the lldb_private::Type, lldb_private::CompilerType, lldb_private::CompilerDecl, lldb_private::CompilerDeclContext.

If there are any regressions in DWARF with DWO, we will need to fix any issues that arise since the original patch wasn't functional for the much more widely used DWARF in .o files with debug map.

<rdar://problem/25200976>

llvm-svn: 264909
2016-03-30 20:14:35 +00:00
Pavel Labath eb0c5c8776 Fix infinite recursion in DWO file parsing
Summary:
Since r264316, clang started adding DW_AT_GNU_dwo_name attribute to dwo files (previously, this
attribute was only present in main object files), breaking pretty much every dwo test. The
problem was that we were treating the presence of said attribute as a signal that we should look
for information in an external object file, and caused us to enter an infinite loop. I fix this
by making sure we do not go looking for an external dwo file if we already *are* parsing a dwo
file.

Reviewers: tberghammer, clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D18547

llvm-svn: 264729
2016-03-29 13:42:02 +00:00
Zachary Turner d133f6acf1 Move some functions from DWARFASTParserClang to ClangASTImporter.
This allows these functions to be re-used by a forthcoming
PDBASTParser.  The functions in question are CanCompleteType,
CompleteType, and CanImport.  Conceptually, these functions belong
on ClangASTImporter anyway, and previously they were just ping
ponging around through a few levels of indirection to end up there
as well, so this patch actually makes the code somewhat simpler.

A few methods were moved to a new file called ClangUtil, so that
they can be shared between ClangASTImporter and ClangASTContext
without creating a circular dependency between those two cpp
files.

Differential Revision: http://reviews.llvm.org/D18381

llvm-svn: 264685
2016-03-28 22:53:41 +00:00
Greg Clayton 6a41dae468 Fixed an case fall through that wasn't meant to happen. Caught by clang's unannotated case fall through warning.
llvm-svn: 263826
2016-03-18 20:36:30 +00:00
Greg Clayton 31460392c1 Fixed a bug where DW_AT_start_scope would fall through to DW_AT_artificial in SymbolFileDWARF::ParseVariableDIE(). This was caught by the clang warning that catches unannotated case fall throughs.
llvm-svn: 263824
2016-03-18 20:33:49 +00:00
Siva Chandra aaae5f87af [DWARFASTParserClang] Start with member offset of 0 for members of union types.
Summary:
GCC does not emit DW_AT_data_member_location for members of a union.
Starting with a 0 value for member locations helps is reading union types
in such cases.

Reviewers: clayborg

Subscribers: ldrumm, lldb-commits

Differential Revision: http://reviews.llvm.org/D18008

llvm-svn: 263085
2016-03-10 01:15:17 +00:00
Zachary Turner 7e8c7bea79 Fix SymbolFilePDB for discontiguous functions.
Previously line table parsing code assumed that the only gaps would
occur at the end of functions.  In practice this isn't true, so this
patch makes the line table parsing more robust in the face of
functions with non-contiguous byte arrangements.

llvm-svn: 263078
2016-03-10 00:06:26 +00:00
Zachary Turner 74e08ca05c Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.

Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows.  This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.

This patch only adds support for line tables.  It does not return
information about functions, types, global variables, or anything
else.  This functionality will be added in a followup patch.

Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton

llvm-svn: 262528
2016-03-02 22:05:52 +00:00
Jim Ingham 406ba45f24 SymbolFileDWARFDebugMap::FindTypes didn't obey the max_matches flag,
but kept looking through .o files even after it had found as many 
matches as were requested.

llvm-svn: 262051
2016-02-26 19:33:11 +00:00
Tamas Berghammer 87a9769e9b Add a set of new plugins to handle Java debugging
The purpose of these plugins is to make LLDB capable of debugging java
code JIT-ed by the android runtime.

Differential revision: http://reviews.llvm.org/D17616

llvm-svn: 262015
2016-02-26 14:21:23 +00:00
Tamas Berghammer 5b42c7aa25 Add support for DW_OP_push_object_address in dwarf expressions
Additionally fix the type of some dwarf expression where we had a
confusion between scalar and load address types after a dereference.

Differential revision: http://reviews.llvm.org/D17604

llvm-svn: 262014
2016-02-26 14:21:10 +00:00
Greg Clayton cec91ef921 Fix all of the unannotated switch cases to annotate the fall through or do the right thing and break.
llvm-svn: 261950
2016-02-26 01:20:20 +00:00
Tamas Berghammer 72ac8a840f Handle the case when a variable is only valid in part of the enclosing scope
DWARF stores this information in the DW_AT_start_scope attribute. This
CL add support for this attribute and also changes the functions
displaying frame variables to only display the variables currently in
scope.

Differential revision: http://reviews.llvm.org/D17449

llvm-svn: 261858
2016-02-25 12:23:37 +00:00
Sean Callanan 99cb022400 Fixed a problem where the DWARF for inline functions was mis-parsed.
Inline functions in DWARF have AT_abstract_origin set, but we only handled that
if the functions were C++ methods.  Inline functions -- C or C++ -- have this
also, and as a result they got one FunctionDecl for each inlined instance.  When
going to construct the locals, this meant that the arguments (which did properly
have their abstract origins handled) would get associated with the master
FunctionDecl, and the inlined FunctionDecls would all appear to have no locals.

This manifested as not being able to look up local variables when stopped in an
inline fuunction.  We should have had a test for this, but somewhere along the
line the relevant test case lost its .py file (or it never had one).

This patch fixes this problem and restores the .py file.

<rdar://problem/24712434>

llvm-svn: 261598
2016-02-23 00:51:52 +00:00
Jason Molenda 62e0681afb Add -Wimplicit-fallthrough command line option to clang in
the xcode project file to catch switch statements that have a
case that falls through unintentionally.

Define LLVM_FALLTHROUGH to indicate instances where a case has code
and intends to fall through.  This should be in llvm/Support/Compiler.h;
Peter Collingbourne originally checked in there (r237766), then
reverted (r237941) because he didn't have time to mark up all the
'case' statements that were intended to fall through.  I put together
a patch to get this back in llvm http://reviews.llvm.org/D17063 but
it hasn't been approved in the past week.  I added a new
lldb-private-defines.h to hold the definition for now.

Every place in lldb where there is a comment that the fall-through
is intentional, I added LLVM_FALLTHROUGH to silence the warning.
I haven't tried to identify whether the fallthrough is a bug or
not in the other places.

I haven't tried to add this to the cmake option build flags.
This warning will only work for clang.

This build cleanly (with some new warnings) on macosx with clang
under xcodebuild, but if this causes problems for people on other
configurations, I'll back it out.

llvm-svn: 260930
2016-02-16 04:14:33 +00:00
Greg Clayton 9ddad935b9 Don't crash if we have a DIE that has a DW_AT_ranges attribute and yet the SymbolFileDWARF doesn't have a DebugRanges. If this happens print a nice error message to prompt the user to file a bug and attach the offending DWARF file so we can get the correct compiler fixed.
<rdar://problem/24458016>

llvm-svn: 260626
2016-02-12 00:07:16 +00:00
Greg Clayton 565aaf6194 Removed a bad assertion:
assert(((SymbolFileDWARF*)m_ast.GetSymbolFile())->UserIDMatches(die.GetDIERef().GetUID()) &&
       "Adding incorrect type to forward declaration map");

The problem is that "m_ast.GetSymbolFile()" can return a SymbolFileDWARFDebugMap. The code is doing the right thing if the assertion is ignored.

<rdar://problem/24437972>

llvm-svn: 260618
2016-02-11 23:36:57 +00:00
Greg Clayton ae088e52f3 Now that SymbolFileDWARF supports having types in completely separate .pcm file with "-fmodules -gmodules", each SymbolFileDWARF can reference module DWARF info by looking in other DWARF files. Then if you have 1000 .o files that each reference one or more .pcm files in their debug info, a simple Module::FindTypes(...) call can end up searching the same .pcm file over and over and over. Now all internal FindTypes methods in classes (ModuleList, Module, SymbolFile) now take an extra argument:
llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files
    
Each time a SymbolFile::FindTypes() is called, it needs to check the searched_symbol_files list to make sure it hasn't already been asked to find the type and return immediately if it has been checked. This will stop circular dependencies from also crashing LLDB during type queries. 

This has proven to be an issue when debugging large applications on MacOSX that use DWARF in .o files. 

<rdar://problem/24581488>

llvm-svn: 260434
2016-02-10 21:28:13 +00:00
Greg Clayton 343f898443 Added code that was commented out during testing to stops template member functions from being added to class definitions (see revision 260308 for details).
<rdar://problem/24483905>
<rdar://problem/24508374>

llvm-svn: 260322
2016-02-09 23:25:54 +00:00
Greg Clayton fb85e6288b Fixed many issues that were causing differing type definition issues to show up when parsing expressions.
1) Turns out we weren't correctly uniquing types for C++. We would search our repository for "lldb_private::Process", but yet store just "Process" in the unique type map. Now we store things correctly and correctly unique types.
2) SymbolFileDWARF::CompleteType() can be called at any time in order to complete a C++ or Objective C class. All public inquiries into the SymbolFile go through SymbolVendor, and SymbolVendor correctly takes the module lock before it call the SymbolFile API call, but when we let CompilerType objects out in the wild, they can complete themselves at any time from the expression parser, so the ValueObjects or (SBValue objects in the public API), and many more places. So we now take the module lock when completing a type to avoid two threads being in the SymbolFileDWARF at the same time.
3) If a class has a template member function like:

    class A
    { 
        <template T>
        void Foo(T t);
    };
    
    The DWARF will _only_ contain a DW_TAG_subprogram for "Foo" if anyone specialized it. This would cause a class definition for A inside a.cpp that used a "int" and "float" overload to look like:
    class A
    {
        void Foo(int t);
        void Foo(double t);
    };
    
    And a version from b.cpp that used a "float" overload to look like:
    class A
    {
        void Foo(float t);
    };

    And a version from c.cpp that use no overloads to look like:    
    
    class A
    {
    };
    
    Then in an expression if you have two variables, one name "a" from a.cpp in liba.dylib, and one named "b" from b.cpp in libb.dylib, you will get conflicting definitions for "A" and your expression will fail. This all stems from the fact that DWARF _only_ emits template specializations, not generic definitions, and they are only emitted if they are used. There are two solutions to this:
    a) When ever you run into ANY class, you must say "just because this class doesn't have templatized member functions, it doesn't mean that any other instances might not have any, so when ever I run into ANY class, I must parse all compile units and parse all instances of class "A" just in case it has member functions that are templatized.". That is really bad because it means you always pull in ALL DWARF that contains most likely exact duplicate definitions of the class "A" and you bloat the memory that the SymbolFileDWARF plug-in uses in LLDB (since you pull in all DIEs from all compile units that contain a "A" definition) uses for little value most of the time.
    b) Modify DWARF to emit generic template member function definitions so that you know from looking at any instance of class "A" wether it has template member functions or not. In order to do this, we would have to have the ability to correctly parse a member function template, but there is a compiler bug: 
    <rdar://problem/24515533> [PR 26553] C++ Debug info should reference DW_TAG_template_type_parameter
    This bugs means that not all of the info needed to correctly make a template member function is in the DWARF. The main source of the problem is if we have DWARF for a template instantiation for "int" like: "void A::Foo<int>(T)" the DWARF comes out as "void A::Foo<int>(int)" (it doesn't mention type "T", it resolves the type to the specialized type to "int"). But if you actually have your function defined as "<template T> void Foo(int t)" and you only use T for local variables inside the function call, we can't correctly make the function prototype up in the clang::ASTContext. 
    
    So the best we can do for now we just omit all member functions that are templatized from the class definition so that "A" never has any template member functions. This means all defintions of "A" look like:
    
    class A
    {
    };
    
    And our expressions will work. You won't be able to call template member fucntions in expressions (not a regression, we weren't able to do this before) and if you are stopped in a templatized member function, we won't know that are are in a method of class "A". All things we should fix, but we need <rdar://problem/24515533> fixed first, followed by:
    
    <rdar://problem/24515624> Classes should always include a template subprogram definition, even when no template member functions are used
    
    before we can do anything about it in LLDB.

This bug mainly fixed the following Apple radar:

<rdar://problem/24483905>

llvm-svn: 260308
2016-02-09 22:36:24 +00:00
Ewan Crawford 75f0ff5ba1 [RenderScript] Use LLVM DWARF language enum
A DWARF language vender extension for RenderScript was added to LLVM in r259348(http://reviews.llvm.org/D16409)
We should use this generated enum instead of the hardcoded value.

RenderScript is also based on C99 with some extensions, so we want to use ClangASTContext when RS is detected.

Reviewers:  clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16766

llvm-svn: 259634
2016-02-03 09:17:03 +00:00
Eugene Zelenko c33088f41e Remove autoconf support from source directories.
Differential revision: http://reviews.llvm.org/D16662

llvm-svn: 259098
2016-01-28 22:05:24 +00:00
Greg Clayton a5d1f62d2d Always try to read DW_TAG_typedef types from DWO files first if we can.
A lot of C code uses code like:

typedef struct 
{
   int a;
} FooType;
          
This creates debug info with an anonymous struct (a DW_TAG_structure_type with no DW_AT_name) and then a DW_TAG_typedef that points to the anonymous structure type. When a typedef is from a module and clang uses -gmodules and -fmodules, then we can end up trying to resolve an anonymous structure type in a DWO symbol file. This doesn't work very well when the structuture has no name, so we now check if a typedef comes from a module, and we directly resolve the typedef type in the module and copy it over. The version we copy from the module of course is correctly able to find the structure in the DWO symbol file, so this fixes the issues we run into.

<rdar://problem/24092915> 

llvm-svn: 258443
2016-01-21 22:26:13 +00:00
Sean Callanan e594268e37 Removed a redundant function call after review.
llvm-svn: 257818
2016-01-14 22:05:26 +00:00
Sean Callanan b0300a4c30 Enable the use of modules in the expression parser by default.
If your program refers to modules (as indicated in DWARF) we will now try to
load these modules and give you access to their types in expressions.  This used
to be gated by a setting ("settings set target.auto-import-clang-modules true")
but that setting defaulted to false.  Now it defaults to true -- but you can
disable it by toggling the setting to false.

llvm-svn: 257812
2016-01-14 21:46:09 +00:00
Sean Callanan 9b0cfe2510 Fixed a crasher when dealing with table entries that have blank names.
This can happen with -gmodules tables when an anonymous struct is referred to.

llvm-svn: 257786
2016-01-14 18:59:49 +00:00
Tamas Berghammer 808ff186f6 Silence an incorrect dwarf parsing warning
We have a check what warns if the offset of a class member is greater
then or equal to the size of the class. The warning is valid in most
case but it is invalid when the last data member is a 0 size array
because in this case the member offset can be equal to the class size
(subject to alignment limitations).

This CL fixis LLDB to not print out a warning in this special case.

llvm-svn: 257603
2016-01-13 14:58:48 +00:00
Tamas Berghammer 1966ac36a6 Don't try to parse the line table when it isn't specified
Previously we tried to parse the line table even if a compile unit
had no DW_AT_stmt_list atribute. The problem happens when a compiler
generates debug info for a compile unit but doesn't generate any line
info.

llvm-svn: 257335
2016-01-11 14:56:05 +00:00
Siva Chandra 9293fc4185 Better scheme to lookup alternate mangled name when looking up function address.
Summary:
This change is relevant for inferiors compiled with GCC. GCC does not
emit complete debug info for std::basic_string<...>, and consequently, Clang
(the LLDB compiler) does not generate correct mangled names for certain
functions.

This change removes the hard-coded alternate names in
ItaniumABILanguageRuntime.cpp.

Before the hard-coded names were put in ItaniumABILanguageRuntime.cpp, one could
not evaluate std::string methods (ex. std::string::length). After putting in
the hard-coded names, one could evaluate them. However, it did not still
enable one to call methods on, say for example, std::vector<string>.
This change makes that possible.

There is some amount of incompleteness in this change. Consider the
following example:

std::string hello("hello"), world("world");
std::map<std::string, std::string> m;
m[hello] = world;

One can still not evaluate the expression "m[hello]" in LLDB. Will
address this issue in another pass.

Reviewers: jingham, vharron, evgeny777, spyffe, dawn

Subscribers: clayborg, dawn, lldb-commits

Differential Revision: http://reviews.llvm.org/D12809

llvm-svn: 257113
2016-01-07 23:32:34 +00:00
Ewan Crawford 7093cccf92 Revert r256769
Reverts "Use correct format identifiers to print something meaningful."

Original format specifiers were correct.
Instead use void* casts to remove warnings, since this is what the %p specifier expects.

llvm-svn: 256833
2016-01-05 13:18:46 +00:00
Davide Italiano e8e7bfbf16 Use correct format identifiers to print something meaningful.
llvm-svn: 256769
2016-01-04 19:17:14 +00:00