In this way, when a language needs to tell itself things that are not bound to a type but to a value (imagine a base-class relation, this is not about the type, but about the ValueObject), it can do so in a clean and general fashion
The interpretation of the values of the flags is, of course, up to the language that owns the value (the value object's runtime language, that is)
llvm-svn: 252503
Summary:
Since this is within the lldb namespace, the compiler tries to
export a symbol for it. Unfortunately, since it is inlined, the
symbol is hidden and this results in a mess of warnings when
building on OS X with cmake.
Moving it to the lldb_private namespace eliminates that problem.
Reviewers: clayborg
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D14417
llvm-svn: 252396
vendors & oses, especially on Apple, to handle the new environment
where we have more than macosx or ios (now we have watchos and tvos).
llvm-svn: 252264
Summary:
The reason for it is limit of detecting ncurses on various systems. For
example, Ubuntu ships with <curses.h> and linkage from <ncurses.h>, <ncurses.h>
isn't detected by CMake. Detecting `<curses.h>` on NetBSD is reusing
conflicting header from the host curses(8) and pkgsrc's ncurses library.
ncurses ships on most (till conflicting) systems with curses.h. On NetBSD it
might be conflicting, so the ncurses headers are installed with pkgsrc to a
subdirectory "ncurses/".
Patch by Kamil Rytarowski. Thanks!
Reviewers: clayborg
Subscribers: youri, akat1, brucem, joerg, lldb-commits
Differential Revision: http://reviews.llvm.org/D14037
llvm-svn: 252250
The Timer class already had some support for multi-threaded access
but it still contained several race conditions. This CL fixes them
in preparation of adding multi-threaded dwarf parsing (and other
multi-threaded parts later).
Differential revision: http://reviews.llvm.org/D13940
llvm-svn: 251105
libraries" altogether. On Mac/iOS, these are libraries which have
a UUID and nlist records but no text or data. If one of these
gets into the global module list, every time we try to search
for a given filename/arch/UUID, we'll get this stub library back.
We need to prevent them from getting added to the module list
altogether.
I thought about doing this down in ObjectFileMachO -- just rejecting
the file as a valid binary file altogether -- but Greg didn't want
to take that hard line approach at this point, he wanted to keep
the ability for lldb to read one of these if someone wanted to in
the future.
<rdar://problem/23035075>
llvm-svn: 250979
Before, in the absence of any configured REPLs, LLDB would act as if there were
multiple possible REPL options, whereas actually no REPL language is supported.
Now we make a better error.
llvm-svn: 250931
Summary:
Along with this, support for an optional argument to the "num_children"
method of a Python synthetic child provider has also been added. These have
been added with the following use case in mind:
Synthetic child providers currently have a method "has_children" and
"num_children". While the former is good enough to know if there are
children, it does not give any insight into how many children there are.
Though the latter serves this purpose, calculating the number for children
of a data structure could be an O(N) operation if the data structure has N
children. The new method added in this change provide a middle ground.
One can call GetNumChildren(K) to know if a child exists at an index K
which can be as large as the callers tolerance can be. If the caller wants
to know about children beyond K, it can make an other call with 2K. If the
synthetic child provider maintains state about it counting till K
previosly, then the next call is only an O(K) operation. Infact, all
calls made progressively with steps of K will be O(K) operations.
Reviewers: vharron, clayborg, granata.enrico
Subscribers: labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D13778
llvm-svn: 250930
This makes LLDB launch and create a REPL, specifying no target so that the REPL
can create one for itself. Also added the "--repl-language" option, which
specifies the language to use. Plumbed the relevant arguments and errors
through the REPL creation mechanism.
llvm-svn: 250773
A REPL takes over the command line and typically treats input as source code.
REPLs can also do code completion. The REPL class allows its subclasses to
implement the language-specific functionality without having to know about the
IOHandler-specific internals.
Also added a PluginManager-based way of getting to a REPL given a language and
a target.
Also brought in some utility code and expression options that are useful for
REPLs, such as line offsets for expressions, ANSI terminal coloring of errors,
and a few IOHandler convenience functions.
llvm-svn: 250753
There were a number of const qualifiers being cast away which caused warnings.
This cluttered the output hiding real errors. Silence them by explicit casting.
NFC.
llvm-svn: 250662
Previous commit r250281 broke TestDataFormatterSmartArray.py
Resolved in in this patch by adding the new enum eFormatVectorOfFloat16 to FormatManager.
Differential Revision: http://reviews.llvm.org/D13730
llvm-svn: 250499
Previously ConstString had a single mutex guarding the global string
pool for each access what become a bottleneck when using it with a
large number of threads.
This CL distributes the strings to 256 individual string pools based on
a simple hash function to eliminate the bottleneck and speed up the
multi-thread access.
The goal of the change is to prepare to multi-threaded symbol parsing code
to speed up the symbol parsing speed.
Differential revision: http://reviews.llvm.org/D13652
llvm-svn: 250289
This patch adds the command 'language renderscript allocation dump <ID>' for printing the contents of a RS allocation.
Displaying the coordinate of each element as well as its formatted value
e.g (lldb) language renderscript allocation dump 1
Data (X, Y, Z):
(0, 0, 0) = {0 1}
(1, 0, 0) = {2 3}
(2, 0, 0) = {4 5}
A --file <filename> option is also included, since for large allocations it may be more helpful to view this text as a file.
Reviewed by: jingham, clayborg
Subscribers: lldb-commits, ADodds, domipheus, brucem
Differential Revision: http://reviews.llvm.org/D13699
llvm-svn: 250281
* ArchSpec::MergeFrom() would erroneously promote an unspecified
unknown to a specified unknown when both the ArchSpec and the merged
in ArchSpec were both unspecified unknowns. This no longer happens,
which fixes issues with global module cache lookup in some
situations.
* Added ArchSpec::DumpTriple(Stream&) that now properly prints
unspecified unknowns as '*' and specified unknows as 'unknown'.
This makes it trivial to tell the difference between the two.
Converted printing code over ot using DumpTriple() rather than
building from scratch.
* Fixed up a couple places that were not guaranteeing that an
unspecified unknown was recorded as such.
llvm-svn: 250253
The underlying raw_string_stream buffer was not being flushed
after asking llvm to collect the backtrace. This worked fine
on OS X but was failing to print anything on Linux.
llvm-svn: 249930
when they introduced android testsuite regressions. Pavel has run the
testsuite against the updated patch and it completes cleanly now.
The original commit message:
Fixing a subtle issue on Mac OS X systems with dSYMs (possibly
introduced by r235737 but I didn't look into it too closely).
A dSYM can have a per-UUID plist in it which tells lldb where
to find an executable binary for the dSYM (DBGSymbolRichExecutable)
- other information can be included in this plist, like how to
remap the source file paths from their build pathnames to their
long-term storage pathnames.
This per-UUID plist is a unusual; it is used probably exclusively
inside apple with our build system. It is not created by default
in normal dSYMs.
The problem was like this:
1. lldb wants to find an executable, given only a UUID
(this happens when lldb is doing cross-host debugging
and doesn't have a copy of the target system's binaries)
2. It eventually calls LocateMacOSXFilesUsingDebugSymbols
which does a spotlight search for the dSYM on the local
system, and failing that, tries the DBGShellCommands
command to find the dSYM.
3. It gets a dSYM. It reads the per-UUID plist in the dSYM.
The dSYM has a DBGSymbolRichExecutable kv pair pointing to
the binary on a network filesystem.
4. Using the binary on the network filesystem, lldb now goes
to find the dSYM.
5. It starts by looking for a dSYM next to the binary it found.
6. lldb is now reading the dSYM over a network filesystem,
ignoring the one it found on its local filesystem earlier.
Everything still *works* but it's much slower.
This would be a tricky one to write up in a testsuite case;
you really need the binary to not exist on the local system.
And LocateMacOSXFilesUsingDebugSymbols will only compile on
Mac OS X - even if I found a way to write up a test case, it
would not run anywhere but on a mac.
One change Greg wanted while I was touching this code was to
have LocateMacOSXFilesUsingDebugSymbols (which could be asked
to find a binary OR find a dSYM) to instead return a ModuleSpec
with the sum total of everything it could find. This
change of passing around a ModuleSpec instead of a FileSpec
was percolated up into ModuleList::GetSharedModule.
The changes to LocateMacOSXFilesUsingDebugSymbols look larger
than they really are - there's a lot of simple whitespace changes
in there.
I ran the testsuites on mac, no new regressions introduced
<rdar://problem/21993813>
llvm-svn: 249755
This involved changing the TypeSystem::CreateInstance to take a module or a target. This allows type systems to create an AST for modules (no expression support needed) or targets (expression support is needed) and return the correct class instance for both cases.
llvm-svn: 249747
Summary:
In bug 24074, the type information is not shown
correctly. This commit includes the following -
-> Changes for displaying correct type based on
current lexical scope for the command "image
lookup -t"
-> The corresponding testcase.
-> This patch was reverted due to segfaults in
FreeBSD and Mac, I fixed the problems for both now.
Reviewers: emaste, granata.enrico, jingham, clayborg
Differential Revision: http://reviews.llvm.org/D13290
llvm-svn: 249673
The ClangExpressionVariable::CreateVariableInList functions looked cute, but
caused more confusion than they solved. I removed them, and instead made sure
that there are adequate facilities for easily adding newly-constructed
ExpressionVariables to lists.
I also made some of the constructors that are common be generic, so that it's
possible to construct expression variables from generic places (like the ABI and
ValueObject) without having to know the specifics about the class.
llvm-svn: 249095
Also added some target-level search functions so that persistent variables and
symbols can be searched for without hand-iterating across the map of
TypeSystems.
llvm-svn: 249027
introduced by r235737 but I didn't look into it too closely).
A dSYM can have a per-UUID plist in it which tells lldb where
to find an executable binary for the dSYM (DBGSymbolRichExecutable)
- other information can be included in this plist, like how to
remap the source file paths from their build pathnames to their
long-term storage pathnames.
This per-UUID plist is a unusual; it is used probably exclusively
inside apple with our build system. It is not created by default
in normal dSYMs.
The problem was like this:
1. lldb wants to find an executable, given only a UUID
(this happens when lldb is doing cross-host debugging
and doesn't have a copy of the target system's binaries)
2. It eventually calls LocateMacOSXFilesUsingDebugSymbols
which does a spotlight search for the dSYM on the local
system, and failing that, tries the DBGShellCommands
command to find the dSYM.
3. It gets a dSYM. It reads the per-UUID plist in the dSYM.
The dSYM has a DBGSymbolRichExecutable kv pair pointing to
the binary on a network filesystem.
4. Using the binary on the network filesystem, lldb now goes
to find the dSYM.
5. It starts by looking for a dSYM next to the binary it found.
6. lldb is now reading the dSYM over a network filesystem,
ignoring the one it found on its local filesystem earlier.
Everything still *works* but it's much slower.
This would be a tricky one to write up in a testsuite case;
you really need the binary to not exist on the local system.
And LocateMacOSXFilesUsingDebugSymbols will only compile on
Mac OS X - even if I found a way to write up a test case, it
would not run anywhere but on a mac.
One change Greg wanted while I was touching this code was to
have LocateMacOSXFilesUsingDebugSymbols (which could be asked
to find a binary OR find a dSYM) to instead return a ModuleSpec
with the sum total of everything it could find. This
change of passing around a ModuleSpec instead of a FileSpec
was percolated up into ModuleList::GetSharedModule.
The changes to LocateMacOSXFilesUsingDebugSymbols look larger
than they really are - there's a lot of simple whitespace changes
in there.
I ran the testsuites on mac, no new regressions introduced
<rdar://problem/21993813>
llvm-svn: 248985
the corresponding TypeSystem. This makes sense because what kind of data there
is -- and how it can be looked up -- depends on the language.
Functionality that is common to all type systems is factored out into
PersistentExpressionState.
llvm-svn: 248934
There are still a bunch of dependencies on the plug-in, but this helps to
identify them.
There are also a few more bits we need to move (and abstract, for example the
ClangPersistentVariables).
llvm-svn: 248612
Summary:
In bug 24074, the type information is not shown
correctly. This commit includes the following -
-> Changes for displaying correct type based on
current lexical scope for the command "image
lookup -t"
-> The corresponding testcase.
Reviewers: jingham, ovyalov, spyffe, richard.mitton, clayborg
Differential Revision: http://reviews.llvm.org/D12404
llvm-svn: 248366
This is meant to cover cases such as the obvious
Base *base = new Derived();
where GetDynamicTypeAndAddress(base) would return the type "Derived", not "Derived *"
llvm-svn: 248315
Summary:
Normally, these macros are defined in fnctl.h. However, GLIBC exposes their
definition through <sys/file.h> too. This change allows us to compile
LLDB with non-GLIBC C libraries.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13022
llvm-svn: 248255
Summary:
With the recent changes to separate clang from the core structures
of LLDB, many inclusions of clang headers can be removed.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12954
llvm-svn: 248004
For C++ and ObjC, dynamic values are always (at least somewhat) pointer-like in nature, so a ValueType of scalar is actually good enough that it could originally be hardcoded as the right choice
Other languages, might have broader notions of things that are dynamic (e.g. a language where a value type can be dynamic). In those cases, it might actually be the case that a dynamic value is a pointer-to the data, or even a host address if dynamic expression results entirely in host space are being talked about
This patch enables the language runtime to make that decision, and makes ValueObjectDynamicValue comply with it
llvm-svn: 247957
This cleans up type systems to be more pluggable. Prior to this we had issues:
- Module, SymbolFile, and many others has "ClangASTContext &GetClangASTContext()" functions. All have been switched over to use "TypeSystem *GetTypeSystemForLanguage()"
- Cleaned up any places that were using the GetClangASTContext() functions to use TypeSystem
- Cleaned up Module so that it no longer has dedicated type system member variables:
lldb::ClangASTContextUP m_ast; ///< The Clang AST context for this module.
lldb::GoASTContextUP m_go_ast; ///< The Go AST context for this module.
Now we have a type system map:
typedef std::map<lldb::LanguageType, lldb::TypeSystemSP> TypeSystemMap;
TypeSystemMap m_type_system_map; ///< A map of any type systems associated with this module
- Many places in code were using ClangASTContext static functions to place with CompilerType objects and add modifiers (const, volatile, restrict) and to make typedefs, L and R value references and more. These have been made into CompilerType functions that are abstract:
class CompilerType
{
...
//----------------------------------------------------------------------
// Return a new CompilerType that is a L value reference to this type if
// this type is valid and the type system supports L value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetLValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType that is a R value reference to this type if
// this type is valid and the type system supports R value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetRValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a const modifier to this type if
// this type is valid and the type system supports const modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddConstModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a volatile modifier to this type if
// this type is valid and the type system supports volatile modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddVolatileModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a restrict modifier to this type if
// this type is valid and the type system supports restrict modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddRestrictModifier () const;
//----------------------------------------------------------------------
// Create a typedef to this type using "name" as the name of the typedef
// this type is valid and the type system supports typedefs, else return
// an invalid type.
//----------------------------------------------------------------------
CompilerType
CreateTypedef (const char *name, const CompilerDeclContext &decl_ctx) const;
};
Other changes include:
- Removed "CompilerType TypeSystem::GetIntTypeFromBitSize(...)" and CompilerType TypeSystem::GetFloatTypeFromBitSize(...) and replaced it with "CompilerType TypeSystem::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding encoding, size_t bit_size);"
- Fixed code in Type.h to not request the full type for a type for no good reason, just request the forward type and let the type expand as needed
llvm-svn: 247953
The Go runtime schedules user level threads (goroutines) across real threads.
This adds an OS plugin to create memory threads for goroutines.
It supports the 1.4 and 1.5 go runtime.
Differential Revision: http://reviews.llvm.org/D5871
llvm-svn: 247852
"gcc" register numbers are now correctly referred to as "ehframe"
register numbers. In almost all cases, ehframe and dwarf register
numbers are identical (the one exception is i386 darwin where ehframe
regnums were incorrect).
The old "gdb" register numbers, which I incorrectly thought were
stabs register numbers, are now referred to as "Process Plugin"
register numbers. This is the register numbering scheme that the
remote process controller stub (lldb-server, gdbserver, core file
support, kdp server, remote jtag devices, etc) uses to refer to the
registers. The process plugin register numbers may not be contiguous
- there are remote jtag devices that have gaps in their register
numbering schemes.
I removed all of the enums for "gdb" register numbers that we had
in lldb - these were meaningless - and I put LLDB_INVALID_REGNUM
in all of the register tables for the Process Plugin regnum slot.
This change is almost entirely mechnical; the one actual change in
here is to ProcessGDBRemote.cpp's ParseRegisters() which parses the
qXfer:features:read:target.xml response. As it parses register
definitions from the xml, it will assign sequential numbers as the
eRegisterKindLLDB numbers (the lldb register numberings must be
sequential, without any gaps) and if the xml file specifies register
numbers, those will be used as the eRegisterKindProcessPlugin
register numbers (and those may have gaps). A J-Link jtag device's
target.xml does contain a gap in register numbers, and it only
specifies the register numbers for the registers after that gap.
The device supports many different ARM boards and probably selects
different part of its register file as appropriate.
http://reviews.llvm.org/D12791
<rdar://problem/22623262>
llvm-svn: 247741
It is required because of the following edge case on arm:
bx <addr> Non-tail call in a no return function
[data-pool] Marked with $d mapping symbol
The return address of the function call will point to the data pool but
we have to treat it as code so the StackFrame can calculate the symbols
correctly.
Differential revision: http://reviews.llvm.org/D12556
llvm-svn: 246958
stores information about a variable that different parts of LLDB use, from the
compiler-specific portion that only the expression parser cares about.
http://reviews.llvm.org/D12602
llvm-svn: 246871
* Change Module::MatchesModuleSpec to return true in case the file spec
in the specified module spec matches with the platform file spec, but
not with the local file spec
* Change the module_resolver used when resolving a remote shared module
to always set the platform file spec to the file spec requested
Differential revision: http://reviews.llvm.org/D12601
llvm-svn: 246852
Summary:
This doesn't exist in other LLVM projects any longer and doesn't
do anything.
Reviewers: chaoren, labath
Subscribers: emaste, tberghammer, lldb-commits, danalbert
Differential Revision: http://reviews.llvm.org/D12586
llvm-svn: 246749
This is still something I need to fix, but at least it's not so ugly, and it's
consistent with the other code that does that so we will catch it when we purge
all such code.
llvm-svn: 246738
Clang-specific part, create the ExpressionVariable source/header file and
move ClangExpressionVariable into the Clang expression parser plugin.
It is expected that there are some ugly #include paths... these will be resolved
by either (1) making that code use generic expression variables (once they're
separated appropriately) or (2) moving that code into a plug-in, often
the expression parser plug-in.
llvm-svn: 246737
Summary:
When calling find_first_of and find_last_of on a single character,
we can instead just call find / rfind and make our intent more
clear.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12518
llvm-svn: 246609
The Language plugin is menat to answer language-specific questions that are not bound to the existence of a process. Those are still the domain of the LanguageRuntime plugin
The Language plugin will, instead, answer questions such as providing language-specific data formatters or expression evaluation
At the moment, the interface is hollowed out, and empty do-nothing plugins have been setup for ObjC, C++ and ObjC++
llvm-svn: 246212
SUMMARY:
This patch implements Target::GetBreakableLoadAddress() method that takes an address
and checks for any reason there is a better address than this to put a breakpoint on.
If there is then return that address.
MIPS uses this method to avoid breakpoint in delay slot.
Reviewers: clayborg, jingham
Subscribers: jingham, mohit.bhakkad, sagar, jaydeep, nitesh.jain, lldb-commits
Differential Revision: http://http://reviews.llvm.org/D12184
llvm-svn: 246015
Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files.
Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types.
Bulk renames for things that used to return a ClangASTType which is now CompilerType:
"Type::GetClangFullType()" to "Type::GetFullCompilerType()"
"Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()"
"Type::GetClangForwardType()" to "Type::GetForwardCompilerType()"
"Value::GetClangType()" to "Value::GetCompilerType()"
"Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)"
"ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()"
many more renames that are similar.
llvm-svn: 245905
The POSIX linker generally reports the load bias for the loaded
libraries but in some case it is useful to handle a library based on
absolute load address. Example usecases:
* Windows linker uses absolute addresses
* Library list came from different source (e.g. /proc/<pid>/maps)
Differential revision: http://reviews.llvm.org/D12233
llvm-svn: 245834
This was breaking disassembly for arm machines that we force to be
thumb mode all the time because we were only checking for llvm::Triple::arm.
i.e.
armv6m (ARM Cortex-M0)
armv7m (ARM Cortex-M3)
armv7em (ARM Cortex-M4)
<rdar://problem/22334522>
llvm-svn: 245645
Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp
Reviewers: tberghammer, ovyalov, clayborg, labath
Subscribers: lldb-commits, nitesh.jain, jaydeep
Differential: http://reviews.llvm.org/D12100
llvm-svn: 245547
Whether or not frames print their tid in hex or decimal is apparently
hardcoded to depend on the operating system. For now a comment was
added that this should be changed to a more sane check (for example
a setting), and the OS check is updated to do the right thing for
Windows.
llvm-svn: 245371
Summary:
in case we are logging to stdout, any log lines from the forked child can be misconstrued to be
inferior output. To avoid this, we disable all logging immediately after forking.
I also fix the implementatoion of DisableAllLogChannels, which was a no-op before this commit.
Reviewers: clayborg, ovyalov
Subscribers: dean, lldb-commits
Differential Revision: http://reviews.llvm.org/D12083
llvm-svn: 245272
Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp
Reviewers: jaydeep, clayborg, jasonmolenda, ovyalov, emaste
Subscribers: tberghammer, ovyalov, emaste, mohit.bhakkad, nitesh.jain, bhushan
Differential: http://reviews.llvm.org/D10919
llvm-svn: 245216
for eh_frame and stabs register numberings. This is not
complete but it's a step in the right direction. It's almost
entirely mechanical.
lldb informally uses "gcc register numbering" to mean eh_frame.
Why? Probably because there's a notorious bug with gcc on i386
darwin where the register numbers in eh_frame were incorrect.
In all other cases, eh_frame register numbering is identical to
dwarf.
lldb informally uses "gdb register numbering" to mean stabs.
There are no official definitions of stabs register numbers
for different architectures, so the implementations of gdb
and gcc are the de facto reference source.
There were some incorrect uses of these register number types
in lldb already. I fixed the ones that I saw as I made
this change.
This commit changes all references to "gcc" and "gdb" register
numbers in lldb to "eh_frame" and "stabs" to make it clear
what is actually being represented.
lldb cannot parse the stabs debug format, and given that no
one is using stabs any more, it is unlikely that it ever will.
A more comprehensive cleanup would remove the stabs register
numbers altogether - it's unnecessary cruft / complication to
all of our register structures.
In ProcessGDBRemote, when we get register definitions from
the gdb-remote stub, we expect to see "gcc:" (qRegisterInfo)
or "gcc_regnum" (qXfer:features:read: packet to get xml payload).
This patch changes ProcessGDBRemote to also accept "ehframe:"
and "ehframe_regnum" from these remotes.
I did not change GDBRemoteCommunicationServerLLGS or debugserver
to send these new packets. I don't know what kind of interoperability
constraints we might be working under. At some point in the future
we should transition to using the more descriptive names.
Throughout lldb we're still using enum names like "gcc_r0" and "gdb_r0",
for eh_frame and stabs register numberings. These should be cleaned
up eventually too.
The sources link cleanly on macosx native with xcode build. I
don't think we'll see problems on other platforms but please let
me know if I broke anyone.
llvm-svn: 245141
Another step towards isolating all language/AST specific code into the files to further abstract specific implementations of parsing types for a given language.
llvm-svn: 245090
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc).
llvm-svn: 244689
This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types to be able to use a type system.
All tests pass on MacOSX and passed on linux the last time this was submitted.
llvm-svn: 244679
This change :
- Fixes offsets of all register sets for Mips.
- Adds MSA register set and FRE=1 mode support for FP register set.
- Separates lldb register numbers and register infos of freebsd/mips64 from linux/mips64.
- Re-orders the register numbers of all kinds for mips to be consistent with freebsd order of register numbers.
- Eliminates ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and uses llvm::APInt and llvm::APFloat for all integer and floating point types.
Reviewers : emaste, jaydeep, clayborg
Subscribers : emaste, mohit.bhakkad, nitesh.jain, bhushan
Differential : http://reviews.llvm.org/D10919
llvm-svn: 244308
Previously embedded interpreters were handled as ad-hoc source
files compiled into source/Interpreter. This made it hard to
disable a specific interpreter, or to add support for other
interpreters and allow the developer to choose which interpreter(s)
were enabled for a particular build.
This patch converts script interpreters over to a plugin-based system.
Script interpreters now live in source/Plugins/ScriptInterpreter, and
the canonical LLDB interpreter, ScriptInterpreterPython, is moved there
as well.
Any new code interfacing with the Python C API must live in this location
from here on out. Additionally, generic code should never need to
reference or make assumptions about the presence of a specific interpreter
going forward.
Differential Revision: http://reviews.llvm.org/D11431
Reviewed By: Greg Clayton
llvm-svn: 243681
The following functions were the only functions that updates the source file:
SourceManager::File::DisplaySourceLines()
SourceManager::File::FindLinesMatchingRegex()
But there we API calls that were using the SourceManager::File and asking it questions, like "is line 12 valid" and that might respond incorrectly if the source file had been updated.
<rdar://problem/21269402>
llvm-svn: 243551
debugging optimized code. Adds new methods on Function/SBFunction
to query whether a given function is optimized. Adds a new
function.is-optimized format entity and changes the default
frame-format to append "[opt]" if the function was built with
optimization.
The only indication that a binary was built with optimization
that we have right now is the presence of the DW_AT_APPLE_optimized
attribute (DW_FORM_flag value 1) in the DW_TAG_compile_unit.
The absence of this flag may mean that the compile_unit was not
compiled with optimization, or it may mean that the producer
does not generate this attribute.
Currently this only works for dSYM debugging. When we create
the CompileUnit with dwarf-in-.o-file debugging we don't have
the attribute value yet so it's not set. I need to find the
flag value when we do start to read the .o file DWARF and
set the CompileUnit's status at that point - but haven't
done it yet.
I'm also going to add a mechanism for issuing warnings to users
such that they're only issued once in a debug session and
there is away for users to suppress these warnings altogether
via .lldbinit file settings. But I want to get this changeset
committed now that it's at a useful state.
<rdar://problem/19281172>
llvm-svn: 243508
This commit introduced an infinite recursion in
ValueObjectChild::CanUpdateWithInvalidExecutionContext (because FollowParentChain also considers
the current object), which broke nearly all the tests. Ignoring the current object removes the
recursion, but two tests still time out (TestDataFormatterLibcxxList.py and
TestValueObjectRecursion.py) for some reason. Reverting for now.
llvm-svn: 243102
If the function is a template then the return type is part of the
function name. This CL fixes the parsing of these function names in
the case when the return type contains ':'.
The name of free functions in C++ don't have context part. Fix the
logic geting the function name without arguments out from a full
function name to handle this case.
Change the handling of step-in-avoid-regexp to match the value against
the function name without it's arguments and return value. This is
required because the default regex ("^std::") would match any template
function returning an std object.
Fifferential revision: http://reviews.llvm.org/D11461
llvm-svn: 243099
The issue is that a child can't really ask the root object, since this decision could actually hinge on whether a dynamic and/or synthetic value is present
To do this, make values vote lazily for whether they are willing to allow this, so that we can navigate up the chain without recursively invoking ourselves
Tentative fix for rdar://21949558
llvm-svn: 243077
Summary:
This enables us to avoid casts to "void *" in some cases and avoids a couple of "casts off const
qualifiers" warnings.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11388
llvm-svn: 242874
Target and breakpoints options were added:
breakpoint set --language lang --name func
settings set target.language pascal
These specify the Language to use when interpreting the breakpoint's
expression (note: currently only implemented for breakpoints on
identifiers). If the breakpoint language is not set, the target.language
setting is used.
This support is required by Pascal, for example, to set breakpoint at 'ns.foo'
for function 'foo' in namespace 'ns'.
Tests on the language were also added to Module::PrepareForFunctionNameLookup
for efficiency.
Reviewed by: clayborg
Subscribers: jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D11119
llvm-svn: 242844
SUMMARY:
The patch detects MIPS application specific extensions (ASE) like micromips by reading
ELF header.e_flags and SHT_MIPS_ABIFLAGS section. MIPS triple does not contain ASE
information like micromips, mips16, DSP, MSA etc. These can be read from header.e_flags
or SHT_MIPS_ABIFLAGS section.
Reviewers: clayborg
Subscribers: mohit.bhakkad, sagar, lldb-commits
Differential Revision: http://reviews.llvm.org/D11133
llvm-svn: 242381
Summary:
Other changes around the main change include:
1. Add a method Cast to ValueObjectConstResult, ValueObjectConstResultImpl
and ValueObjectConstResultChild.
2. Add an argument |live_address| of type lldb::addr_t to the constructor
of ValueObjectConstResultChild. This is passed on to the backing
ValueObjectConstResultImpl object constructor so that the address of the
child value can be calculated properly.
Reviewers: granata.enrico, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11203
llvm-svn: 242374
The size of a long double was hardcoded in DataExtractor for x86 and
x86_64 architectures. This CL removes the hard coded values and use the
actual size based on the floating point semantics specified.
Differential revision: http://reviews.llvm.org/D8417
llvm-svn: 242019
This patch:
- Allows mips32 cores to match with any mips32/mips64 cores.
- Allows mips32r2 cores to match with core only up-to mips32r2/mips64r2.
- Allows mips32r3 cores to match with core only up-to mips32r3/mips64r3.
- Allows mips32r5 cores to match with core only up-to mips32r3/mips64r5.
- Allows mips32r6 core to match with only mips32r6/mips64r6 or mips32/mips64.
Reviewers: emaste, jaydeep, clayborg
Subscribers: mohit.bhakkad, nitesh.jain, bhushan, lldb-commits
Differential Revision: http://reviews.llvm.org/D10921
llvm-svn: 242016
Change over existing code to use this new parser so StructuredData can use the tokenizer to parse JSON instead of doing it manually.
This allowed us to easily parse JSON into JSON* objects as well as into StructuredData.
llvm-svn: 241522
This API is currently a no-op (in the sense that it has the same behavior as the already existing GetName()), but is meant long-term to provide a best-for-visualization version of the name of a function
It is still not hooked up to the command line 'bt' command, nor to the 'gui' mode, but I do have ideas on how to make that work going forward
rdar://21203242
llvm-svn: 241482
* Add in-memory object file handling to the core dynamic loader
* Fix in memory object file handling in ObjectFileELF (previously
only part of the file was loaded before parsing)
* Fix load address setting in ObjectFileELF for 32-bit targets
when the load bias is negative
* Change hack in DYLDRendezvous.cpp to be more specific and not to
interfere with object files with fixed load address
Differential revision: http://reviews.llvm.org/D10800
llvm-svn: 241057
A few extras were fixed
- Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected.
- Since some places want to access the address as a reference, I added a few new functions to symbol:
Address &Symbol::GetAddressRef();
const Address &Symbol::GetAddressRef() const;
Linux test suite passes just fine now.
<rdar://problem/21494354>
llvm-svn: 240702
The language can not be definitively determined from the mangling, so
this new name helps clarify that fact. This addresses the concerns raised
in http://reviews.llvm.org/rL226962.
Reviewed by: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10723
llvm-svn: 240662
Enable ${language} to be specified in the frame-format string to see
the current frame's compile unit language in "frame info".
Test Plan:
debug a C++ program, run to main, and run the lldb commands:
settings set frame-format "frame lang=${language}\n"
frame info
you should see:
frame lang=c++
test case added in:
./dotest.py --executable lldb -f SettingsCommandTestCase.test_set_frame_format
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10561
llvm-svn: 240440
We have been working on reducing the packet count that is sent between LLDB and the debugserver on MacOSX and iOS. Our approach to this was to reduce the packets required when debugging multiple threads. We currently make one qThreadStopInfoXXXX call (where XXXX is the thread ID in hex) per thread except the thread that stopped with a stop reply packet. In order to implement multiple thread infos in a single reply, we need to use structured data, which means JSON. The new jThreadsInfo packet will attempt to retrieve all thread infos in a single packet. The data is very similar to the stop reply packets, but packaged in JSON and uses JSON arrays where applicable. The JSON output looks like:
[
{ "tid":1580681,
"metype":6,
"medata":[2,0],
"reason":"exception",
"qaddr":140735118423168,
"registers": {
"0":"8000000000000000",
"1":"0000000000000000",
"2":"20fabf5fff7f0000",
"3":"e8f8bf5fff7f0000",
"4":"0100000000000000",
"5":"d8f8bf5fff7f0000",
"6":"b0f8bf5fff7f0000",
"7":"20f4bf5fff7f0000",
"8":"8000000000000000",
"9":"61a8db78a61500db",
"10":"3200000000000000",
"11":"4602000000000000",
"12":"0000000000000000",
"13":"0000000000000000",
"14":"0000000000000000",
"15":"0000000000000000",
"16":"960b000001000000",
"17":"0202000000000000",
"18":"2b00000000000000",
"19":"0000000000000000",
"20":"0000000000000000"},
"memory":[
{"address":140734799804592,"bytes":"c8f8bf5fff7f0000c9a59e8cff7f0000"},
{"address":140734799804616,"bytes":"00000000000000000100000000000000"}
]
}
]
It contains an array of dicitionaries with all of the key value pairs that are normally in the stop reply packet. Including the expedited registers. Notice that is also contains expedited memory in the "memory" key. Any values in this memory will get included in a new L1 cache in lldb_private::Process where if a memory read request is made and that memory request fits into one of the L1 memory cache blocks, it will use that memory data. If a memory request fails in the L1 cache, it will fall back to the L2 cache which is the same block sized caching we were using before these changes. This allows a process to expedite memory that you are likely to use and it reduces packet count. On MacOSX with debugserver, we expedite the frame pointer backchain for a thread (up to 256 entries) by reading 2 pointers worth of bytes at the frame pointer (for the previous FP and PC), and follow the backchain. Most backtraces on MacOSX and iOS now don't require us to read any memory!
We will try these packets out and if successful, we should port these to lldb-server in the near future.
<rdar://problem/21494354>
llvm-svn: 240354
Summary:
* Fix enum LanguageType values so that they can be used as indexes
into array language_names and g_languages as assumed by
LanguageRuntime::GetNameForLanguageType,
Language::SetLanguageFromCString and Language::AsCString.
* Add DWARFCompileUnit::LanguageTypeFromDWARF to convert from DWARF
DW_LANG_* values to enum LanguageType values.
Reviewed By: clayborg, abidh
Differential Revision: http://reviews.llvm.org/D10484
llvm-svn: 239963
Setting the OSType in the ArchSpec triple is needed to correctly setup
up the register context plugin. ArchSpec::SetArchitecture, for Mach-O
only, sets the OSType. For ELF it was left to the ObjectFileELF to fill
in the missing OSType.
This change moves the ObjectFileELF logic into ArchSpec.
A new optional 'os' parameter has been added to SetArchitecture.
For ELF, this value is the from the ELF header.e_ident[EI_OSABI].
The default value is 0 or ELFOSABI_NONE.
The real work of determining the OSType was done by the ObjectFileELF
helper function GetOsFromOSABI. This logic has been moved
SetArchitecture.
GetOsFromOSABI has been commented as being deprectated. It is left in
to support asserts.
For ELF the vendor value returned from SetArchitecture should be
UnknownVendor. An unneeded resetting in ObjectFileELF has been removed
and replaced with an assert.
This fixes a problem reading a core file on FreeBSD/ARM because the spec
triple was arm-unknown-unknown.
Patch by Tom Rix.
Differential Revision: http://reviews.llvm.org/D9292
llvm-svn: 239148
This was of course overridable by using DumpValueObjectOptions, but the default should be saner and the previous behavior made for a few fun investigations....
rdar://problem/21065149
llvm-svn: 238961
Enrico Granata