Summary:
Generating LLDB.framework when building with CMake+Ninja will copy the
lldb-private headers because public_headers contains them, even though we try
to make sure they don't get copied by removing root_private_headers from
root_public_headers.
This patch also removes SystemInitializerFull.h from the LLDB.framework headers when building with CMake.
Reviewers: compnerd, sas, labath, beanz, zturner
Reviewed By: labath
Subscribers: clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47278
llvm-svn: 333444
GetUnitDIEPtrOnly() needs to return pointer to the first DIE.
But the first element of m_die_array after ExtractDIEsIfNeeded(true)
may move in memory after later ExtractDIEsIfNeeded(false).
DWARFDebugInfoEntry::collection m_die_array is std::vector,
its data may move during its expansion.
Differential revision: https://reviews.llvm.org/D46810
llvm-svn: 333437
The lldb test suite is highly configurable. While part of this
configuration takes place at configure/build-time, a common scenario
involves running the test suite several times with different
configuration. For example, we might want to test the current lldb
against inferiors built with different compilers.
This configuration was already possible for lldb-dotest, but was lacking
for the lit counterpart. It is now possible to pass arguments to pass
arguments like this:
./bin/llvm-lit ../llvm/tools/lldb/lit/Suite/ -Ddotest-args="-foo;-bar"
llvm-svn: 333432
The framework argument was broken when I removed the generator
expressions upstream. I replaced $<TARGET_FILE_DIR:liblldb> with
${LLVM_LIBRARY_OUTPUT_INTDIR}) which is not correct.
rdar://40534649
llvm-svn: 333412
It's been failing since I enabled the test for non-darwin targets. I
made it reference the same bug as the linux core, as it's likely that
the root cause is the same.
llvm-svn: 333401
Summary:
This improves the process of cross-compiling from macOS to Linux
since these files aren't used / needed at all.
Reviewers: clayborg, labath
Subscribers: lldb-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D47420
llvm-svn: 333400
Summary:
We were treating subprograms and inlined subroutines differently when
building the index. The difference was in which indexes were individual
tags inserted (subprograms went to all indexes, where as inlined
subroutines only into the basename and full name indexes).
This seems like an error, because an inlined subroutine can still
represent an C++ or an ObjC method. I don't see anything in the
subprogram branch which should not apply to an inlined subroutine, so I
propose to just treat them identically. This makes searching for an
inlined method behave the same way as for the apple index.
I write an assembly-based test because I did not want to depend on
particular clang inlining behavior (and because I wanted to see how hard
would it be).
Reviewers: clayborg, JDevlieghere
Subscribers: eraman, lldb-commits
Differential Revision: https://reviews.llvm.org/D47368
llvm-svn: 333398
Summary:
FastDemangle gives us a C-string that we own (which is allocated in SymbolDemangler::GetDemangledCopy).
As we are not deleting the string, we leak memory whenever we call SubsPrimitiveParmItanium.
Reviewers: javed.absar
Subscribers: kristof.beyls, chrib, lldb-commits
Differential Revision: https://reviews.llvm.org/D47418
llvm-svn: 333353
Summary: When compiling with modules, these missing includes cause the build to fail (as the header can't be compiled into a module).
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D47412
llvm-svn: 333345
Summary: This resolves unnecessary the header dependency from
Core to DataFormatters. Patch is necessary for the introduction of
C++ modules to the LLDB build system.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D47409
llvm-svn: 333342
Summary:
It seems to me that files in include/lldb/API/ are headers that should
be exposed to liblldb users. Because SystemInitializerFull.h exposes details of
lldb_private, I think having it there is not the right thing to do. Since it's
only included from files in source/API, we should move it there and treat it as
private.
Reviewers: labath, clayborg
Reviewed By: labath, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D47342
llvm-svn: 333304
Several functions were passing a list of 8 NameToDIE arguments around.
This puts those variables in a struct and passes that instead, reducing
code duplication and the possibility of error (swapping two arguments
accidentally).
llvm-svn: 333264
As suggested by Pavel Labath in D46810 DWARFUnit::GetUnitDIEOnly() returning
a pointer to m_first_die should not permit using methods like GetFirstChild().
Differential revision: https://reviews.llvm.org/D47276
llvm-svn: 333224
This new DWARFBaseDIE is going to be used for DWARFUnit::GetUnitDIEOnly() as
other DIEs are unavailable that time so the caller should not have methods
available to access them.
This patch is only a mechanical split without any use of it.
Differential revision: https://reviews.llvm.org/D47275
llvm-svn: 333222
Now it's possible to set breakpoints before selecting a target, they
will be set to the dummy target and then copied to an each added one.
Patch by Alexander Polyakov!
Differential Revision: https://reviews.llvm.org/D46588
llvm-svn: 333205
Summary:
For lldb-server, it is sufficient to parse only the native object file
format for its target OS (no other file can be loaded into a running
process). This moves the object file initialization code into specific
initializer classes: lldb-test and liblldb get all object files;
lldb-server gets only one of them. For this to work, I've needed to
create a special SystemInitializer for use in lldb-server, instead of it
calling directly into the common one.
This reduces the size of lldb-server by about 2%, which is not
earth-shattering, but it's an easy win, and it helps.
Reviewers: zturner, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47250
llvm-svn: 333182
Summary:
I think this makes sense for several reasons:
- better separation of concerns: DWARFUnit's job should be to provide a
nice interface to its users to access the unit contents.
ManualDWARFIndex can then use this interface to build an index and
provide it to its users.
- closer alignment with llvm parsers: there is no indexing equivalent in
llvm, and there probably never will be, as the index is very centered
around how lldb wants to access debug info. If we ever switch to
llvm's parser, this will allow us swap out DWARFUnit implementations
and keep indexing as-is.
- closer proximity of the indexing code to AppleDWARFIndex will make it
easier to keep the two in sync (e.g. right now the two use very
different algorithms to determine whether a DW_TAG_subroutine
represents a "method"). This is my primary motivation for making this
change now, but I am leaving this work to a separate patch.
The only interface change to DWARFUnit I needed to make was to add an
efficient way to iterate over the list of all DIEs. Adding this also
aligns us closer to the llvm parser.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D47253
llvm-svn: 333178
The only reason this was here was so that Module could have a
function called CreateJITModule which created things in a special
order. Instead of making this specific to creating JIT modules,
I converted this into a template function that can create a module
for any type of object file plugin and just forwards arguments
through. Since the template is not instantiated in Core, the linker
(and header file) dependency moves to the point where it is
instantiated, which only happens in Expression. Conceptually, this
location also makes more sense for a dependency on ObjectFileJIT.
After all, we JIT expressions so it's no surprise that Expression
needs to make use of ObjectFileJIT.
Differential Revision: https://reviews.llvm.org/D47228
llvm-svn: 333143
The tests added in r332842 don't work on windows, because they do path
comparisons on strings, and on windows, the paths coming out of the
mappings had backslashes in them.
This switches comparisons to FileSpecs, so the results come out right.
llvm-svn: 333074
This call was originally being only made when launching for debug (as an
attempt to make sure we don't impart extra privileges on the launched
process), but after the debug and non-debug paths were merged, it made
it's way into generic code. This was causing problems in locked down
android environments which disallowed calling setgid even if it would be
a no-op. This prevented launching llgs from lldb-server platform.
Overall I'm not sure we should be calling setgid in the first place
(it seems random -- e.g. why don't we call setuid then as well).
However, all our other copies of launch code have it, so I choose to
keep it for now.
llvm-svn: 333073
Summary:
Implement FindGlobalVariables and ParseVariableContext methods.
Compile unit information is necessary for resolving variable context, however some PDB symbols do not have this information. For now an empty DWARFExpression is used to construct a lldb::Variable instance with the limitation that using lldb to lookup the value of a global or local variable is not available.
This commit may slow down lit/SymbolFile/PDB/compilands.test since the test includes MS specific modules that spend more time parsing variables.
Reviewers: rnk, zturner, lldb-commits
Subscribers: aprantl, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D45224
llvm-svn: 333049
Use proper cmake techniques to detect where the libedit package resides.
This allows for the use of libedit from an alternative location which is
needed for supporting cross-compilation.
llvm-svn: 333041
Most non-local includes of header files living under lldb/sources/
were specified with the full path starting after sources/. However, in
a few instances, other sub-directories were added to include paths, or
Normalize those few instances to follow the style used by the rest of
the codebase, to make it easier to understand.
llvm-svn: 333035
Summary:
The plugin already builds fine on other platforms (linux, at least). All
that was necessary was to revitalize the hack in PlatformDarwinKernel
(not a very pretty hack, but it gets us going at least).
I haven't done a thorough investigation of the state of the plugin on
other platforms, but at least the two core file tests we have seem to
pass, so I enable them.
Reviewers: JDevlieghere, jasonmolenda
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D47133
llvm-svn: 332997
We've seen some cases on macOS where you go to instruction single
step (over a breakpoint), and single step returns but the instruction
hasn't been executed (and the pc hasn't moved.) The ThreadPlanStepOverBreakpoint
used to handle this case by accident, but the patches to handle two adjacent
breakpoints broke that accident.
This patch fixes the logic of ExplainsStop to explicitly handle the case where
the pc didn't move. It also adds a WillPop that re-enables the breakpoint we
were stepping over. We never want an unexpected path through the plan to
fool us into not doing that.
I have no idea how to make this bug happen. It is very inconsistent when it
occurs IRL. We really need a full MockProcess Plugin before we can start to write
tests for this sort of system hiccup.
<rdar://problem/38505726>
llvm-svn: 332922
PathMappingList was broken for relative and empty paths after normalization changes in FileSpec. There were also no tests for PathMappingList so I added those.
Changes include:
Change PathMappingList::ReverseRemapPath() to take FileSpec objects instead of ConstString. The only client of this was doing work to convert to and from ConstString objects for no reason.
Normalize all paths prefix and replacements that are added to the PathMappingList vector so they match the paths that have been already normalized in the debug info
Unify code in the two forms of PathMappingList::RemapPath() so only one contains the actual functionality. Prior to this, there were two versions of this code.
Use FileSpec::AppendPathComponent() and remove a long standing TODO so paths are correctly appended to each other.
Added tests for absolute, relative and empty paths.
Differential Revision: https://reviews.llvm.org/D47021
llvm-svn: 332842
After closer examination, it turns out we mis-classify one of the
methods only if two of the structs have the same name. Since this was
meant to be a basic test, I rename one of the structs in the test so
that we have at least some coverage for the apple tables lookup.
Instead, I create an XFAILed test which specifically targets the
same-name case (and file a bug to track it).
llvm-svn: 332833
Summary:
Now that we are able to parse MachO files everywhere, we can write some
cross-platform tests for handling of apple accelerator tables. This
reruns the same lookup tests we have for manual indexes on MachO files
which will use the accelerator tables instead. This makes sure we return
the same results regardless of the method we used to access the debug
info.
The tests confirm we return the same results for looking up types,
namespaces and variables, but have found an inconsistency in the
treatment of function lookup. In the function case we mis-classify the
method "foo" declared in the local struct sbar (inside function ffbar).
We classify it as a function whereas it really is a method. Preliminary
analysis suggests this is because
DWARFASTParserClang::GetClangDeclContextForDIE returns null when given
the local "struct sbar" DIE. This causes us to get the wrong
CompilerDeclContext when we ask for the context of the inner foo, which
means CompilerDeclContext::ISStructUnionOrClass returns false.
Until this is fixed, I do not include the darwin versions of the "base"
and "method" function lookup tests.
Reviewers: JDevlieghere, clayborg
Subscribers: aprantl, ilya-biryukov, ioeric, lldb-commits
Differential Revision: https://reviews.llvm.org/D47064
llvm-svn: 332831
Summary:
- Fix #include path
- Fix warning:
````
error: format specifies type 'unsigned long long' but the argument has type 'uint64_t'
(aka 'unsigned long') [-Werror,-Wformat]
```
Reviewers: labath, javed.absar
Differential Revision: https://reviews.llvm.org/D47072
llvm-svn: 332733
Summary:
This places the `if(m_using_apple_tables)` branches inside the
SymbolFileDWARF class behind an abstract DWARFIndex class. The class
currently has two implementations:
- AppleIndex, which searches using .apple_names and friends
- ManualIndex, which searches using a manually built index
Most of the methods of the class are very simple, and simply extract the
list of DIEs for the given name from the appropriate sub-table. The main
exception are the two GetFunctions overloads, which take a couple of
extra paramenters, including some callbacks. It was not possible to
split these up the same way as other methods, as here we were doing a
lot of post-processing on the results. The post-processing is similar
for the two cases, but not identical. I hope to factor these further in
separate patches.
Other interesting methods are:
- Preload(): do any preprocessing to make lookups faster (noop for
AppleIndex, forces a build of the lookup tables for ManualIndex).
- ReportInvalidDIEOffset(): Used to notify the users of an invalid index
(prints a message for AppleIndex, noop for ManualIndex).
- Dump(): dumps the index state (noop for AppleIndex, prints the lookup
tables for ManualIndex).
Reviewers: clayborg, JDevlieghere
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46889
llvm-svn: 332719
It turns out these class still contained some os-specific functionality,
but I did not notice that originally, as it was #ifdef arm(64). This
adds back the __APPLE__ condition to these particular functions,
unbreaking arm builds on other OSs.
llvm-svn: 332710
Summary:
Before this patch we were unable to write cross-platform MachO tests
because the parsing code did not compile on other platforms. The reason
for that was that ObjectFileMachO depended on
RegisterContextDarwin_arm(64)? (presumably for core file parsing) and
the two Register Context classes uses constants from the system headers
(KERN_SUCCESS, KERN_INVALID_ARGUMENT).
As far as I can tell, these two files don't actually interact with the
darwin kernel -- they are used only in ObjectFileMachO and MacOSX-Kernel
process plugin (even though it has "kernel" in the name, this one
communicates with it via network packets and not syscalls). For the time
being I have created OS-independent definitions of these constants and
made the register context classes use those. Long term, the error
handling in these classes should be probably changed to use more
standard mechanisms such as Status or Error classes.
This is the only change necessary (apart from build system glue) to make
ObjectFileMachO work on other platforms. To demonstrate that, I remove
REQUIRES:darwin from our (only) cross-platform mach-o test.
Reviewers: jasonmolenda, aprantl, clayborg, javed.absar
Subscribers: mgorny, lldb-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D46934
llvm-svn: 332702
In r265181 the test for the NSCFBoolean data formatter was removed.
Later, in r279353 and r279446 a new implementation was provided for the
formatter, which I believe never worked (and this wasn't caught because
the test was never re-enabled).
This commit fixes the bug and re-enables the old test case.
Differential revision: https://reviews.llvm.org/D47014
llvm-svn: 332700
Summary: LLDB reads wrong registers on 64bit Windows because RegisterContextWindows_x64::GetRegisterInfoAtIndex returns wrong reference.
I encountered broken backtrace when the program stopped at function which does not have prologue code, such as compiled with '-fomit-frame-pointer'.
In this situation, CFA is equal to rsp but LLDB reads r9.
RegisterContextWindows_x64::GetRegisterInfoAtIndex depends the order of lldb_XXX_x86_64 values, but RegisterIndex/g_register_infos/g_gpr_reg_indices does not follow order.
In source/Plugins/Process/Utility/lldb-x86-register-enums.h
The order of GPRs is rax, rbx, rcx, rdx, rdi, rsi, rbp, rsp, r8, ...
In source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp
The order of GPRs is rax, rbx, rcx, rdx, rdi, rsi, r8, r9, r10, ...
Patch by Kenji Koyanagi
llvm-svn: 332671
Summary: The function ResumeThread on Windows returns a DWORD which is an unsigned int. In TargetThreadWindows::DoResume, there's code that determines how many times to call ResumeThread based on whether the return value is greater than 0. Since the function returns -1 (as an unsigned int) on failure, this was getting stuck in an infinite loop if ResumeThread failed for any reason. The correct thing to do is check whether the return value is -1 and then return the appropriate error instead of ignoring the return value.
Reviewers: asmith, zturner, labath
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47020
llvm-svn: 332670
Summary: These three tests are failing on Windows and looking into the failures, they could be mapped to pr21765 and pr24489
Reviewers: asmith, labath, zturner
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47018
llvm-svn: 332629
After switching to LLVM normalization, if we init FileSpec with "." we would end up with m_directory being NULL and m_filename being "".
This patch fixes this by allowing the path to be normalized and if it normalized to nothing, set it to m_filename.
Differential Revision: https://reviews.llvm.org/D46783
llvm-svn: 332618
Summary:
The DataExtractors are cheap to copy so there is no reason to store them
by reference. Also, in my upcoming indexing refactor I am planning to
remove the apple tables data extractor members from the SymbolFileDWARF
class, so there will not be a DataExtractor with a suitable lifetime to
refer to.
Reviewers: clayborg, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46888
llvm-svn: 332596
Summary:
1) In logtest.cpp, the name of the file that is reported is not always capitalized, so split the comparison to validate the file (case insensitive) and function (case sensitive) separately
2) Update the gdb remote client tests to work with Python 3. In Python 3, socket sends/receives data as bytes rather than byte strings. This also updates the usage of .hex() - this is no longer available in Python 3, so use hexlify instead
Reviewers: asmith, labath, zturner
Reviewed By: labath
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46773
llvm-svn: 332293
The first fix wasn't enough, there is still a missing
ProcessInstanceInfo include in Host.mm. I won't be able to test a fix
before leaving work, so I am reverting both commits.
This reverts commit r332250 and the subsequent fix attempt.
llvm-svn: 332261
The Process class was only being referenced because of the last-ditch
effort in the process launchers to set a process death callback in case
one isn't set already.
Although launching a process for debugging is the most important kind of
"launch" we are doing, it is by far not the only one, so assuming this
particular callback is the one to be used is not a good idea (besides
breaking layering). Instead of assuming a particular exit callback, I
change the launcher code to require the callback to be set by the user (and fix
up the two call sites which did not set the callback already).
Reviewers: jingham, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D46395
llvm-svn: 332250
Summary:
The llvm version of the enum has the same enumerators, with stlightly
different names, so this is mostly just a search&replace exercise. One
concrete benefit of this is that we can remove the function for
converting between the two enums.
To avoid typing llvm::sys::path::Style::windows everywhere I import the
enum into the FileSpec class, so it can be referenced as
FileSpec::Style::windows.
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D46753
llvm-svn: 332247
Pavel Labath found this patch is incomplete and racy. I think there needs to
be some more mutexes even before considering DW_TAG_partial_unit.
This reverts commit 331229 which was: https://reviews.llvm.org/D40470
llvm-svn: 332200
This reverts commit r332162 as it breaks the bots (Ubuntu 14.04)
with the following message:
Build Command Output:
objcopy: option '--compress-debug-sections' doesn't allow an argument
llvm-svn: 332165
Summary:
Multiple threads could be calling into DoLoadImage concurrently,
only one should be allowed to create the UtilityFunction.
Reviewers: jingham
Subscribers: emaste, lldb-commits
Differential Revision: https://reviews.llvm.org/D46733
llvm-svn: 332115
Inside Xcode and in Xcode toolchains LLDB is always in lockstep
with the Swift compiler, so it can reuse its Clang resource
directory. This allows LLDB and the Swift compiler to share the
same Clang module cache.
rdar://problem/40039633
Differential Revision: https://reviews.llvm.org/D46736
llvm-svn: 332111
Summary:
now that llvm supports host-agnostic path manipulation functions (and
most of their kinks have been ironed out), we can remove our copies of
the path parsing functions in favour of the llvm ones.
This should be NFC except for the slight difference in handling of the
"//" path, which is now normalized to "/" (this only applies to the
literal "//" path; "//net" and friends still get to keep the two
slashes).
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D46687
llvm-svn: 332088
Getting the deployment target can be significant information when
rebuilding clang modules since availability information could depend
on it.
rdar://problem/40039633
Differential Revision: https://reviews.llvm.org/D46669
llvm-svn: 332067
I was considering modifying this function, so I wrote some tests to make
sure I don't regress its behavior. I am not sure if I will actually
proceed with the modifications, but the tests seem useful nonetheless.
llvm-svn: 331966
Summary: The current setup for the unit tests only works correctly when the generator does not support multiple configurations. When the generator supports multiple configurations, the inputs are not copied to the correct per-configuration directory. This change sets up the build to copy the inputs in each configuration directory.
Reviewers: labath, asmith, zturner
Reviewed By: labath
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46642
llvm-svn: 331914
This cleanup is designed to make the https://reviews.llvm.org/D32167 patch smaller and easier to read.
Cleanup in this patch:
Allow DWARFUnit subclasses to hand out the data that should be used when decoding data for a DIE. The information might be in .debug_info or could be in .debug_types. There is a new virtual function on DWARFUnit that each subclass must override:
virtual const lldb_private::DWARFDataExtractor &DWARFUnit::GetData() const;
This allows DWARFCompileUnit and eventually DWARFTypeUnit to hand out different data to be used when decoding the DIE information.
Add a new pure virtual function to get the size of the DWARF unit header:
virtual uint32_t DWARFUnit::GetHeaderByteSize() const = 0;
This allows DWARFCompileUnit and eventually DWARFTypeUnit to hand out different offsets where the first DIE starts when decoding DIE information from the unit.
Added a new function to DWARFDataExtractor to get the size of an offset:
size_t DWARFDataExtractor::GetDWARFSizeOfOffset() const;
Removed dead dumping and parsing code in the DWARFDebugInfo class.
Inlined a bunch of calls in DWARFUnit for accessors that were just returning integer member variables.
Renamed DWARFUnit::Size() to DWARFUnit::GetHeaderByteSize() as it clearly states what it is doing and makes more sense.
Differential Revision: https://reviews.llvm.org/D46606
llvm-svn: 331892
Summary:
1) In TestLinuxCore rather than skipping the tests on Windows, mark them as expected failures and add a bug reference
2) In dotest.py replace the undefined property in the exceptions with the actual property causing the exception
Reviewers: asmith, labath, zturner
Reviewed By: labath, zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46590
llvm-svn: 331886
Summary:
The comments on this class were out of date with the implementation, and
the implementation itself was inconsistent with our usage of the Timeout
class (I started converting everything to use this class back in D27136,
but I missed this one). I avoid duplicating the waiting logic by
introducing a templated WaitFor function, and make other functions
delegate to that. This function can be also used as a replacement for
the unused WaitForBitToBeSet functions I removed, if it turns out to be
necessary.
As this changes the meaning of a "zero" timeout, I tracked down all the
callers of these functions and updated them accordingly. Propagating the
changes to all the callers of RunShellCommand was a bit too much for
this patch, so I stopped there and will continue that in a follow-up
patch.
I also add some basic unittests for the functions I modified.
Reviewers: jingham, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D46580
llvm-svn: 331880
Summary:
Before this patch the two paths were doing very different things
- the apple path searched the .apple_names section, which contained
mangled names, as well as basenames of all functions. It returned any
name it found.
- the non-accelerated path looked in the "full name" index we built
ourselves, which contained mangled as well as demangled names of all
functions (but no basenames). Then however, if it did not find a match
it did an extra search in the basename index, with some special
handling for anonymous namespaces.
This aligns the two paths by changing the non-accelerated path to return
the same results as in the apple-tables one. In pratice, this means we
will search in both the "basename", "method" and "fullname" indexes (in
the manual indexes these are separate indexes. This means the function
will return some slightly inappropriate results (e.g. bar::baz::foo when
one asks for a "full name" foo), but this can be handled by additional
filtering, independently indexing method. I've also stopped inserting
demangled names into the "fullname" index, as that is inconsistent with
the apple path.
Reviewers: clayborg, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D46576
llvm-svn: 331855
In an effort to make the .debug_types patch smaller, breaking out the part that reads the .debug_types from object files into a separate patch
Differential Revision: https://reviews.llvm.org/D46529
llvm-svn: 331777
Re-enable TestUnicodeSymbols now that we use the in-tree dsymutil. This
was disabled because the hashing of unicode symbols was out of sync
between llvm (dsymutil) and lldb.
llvm-svn: 331764
Summary:
... and fix one bug found this way. Currently, the test works not because
types are looked up correctly, but because by injecting local variables
we also materialize the types for Clang. If we disable the local variable
injection, then one check fails.
The reason of the failure is that FindTypes is run with max_matches==1
and this value is passed down to the symbol lookup functions. When the
search is performed only on the basename (like it's the case for an
entity defined in the root namespace), then the search will stop after
having found one match on the basename. But that match might be in a
namespace, we were really just looking up the basename in the accelerator
tables.
The solution is to not pass max_matches down, but to search without a
limit and let RemoveMismatchedTypes do its job afterwards. Note the
patch includes 2 hunks with the same change, but only the latter is
tested. I couldn't find a way to create a testcase for the other
branch of the if ('image lookup -t' allows me to get there, but it
only ever returns one type anyway).
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D46548
llvm-svn: 331719
Summary:
In decorators.py, when opening streams, open them in text mode. In Py3, if they are not opened in text mode, the data is also expected to be binary, but we always use text data.
In TestLinuxCore, skip the tests that are not applicable on Windows
In the python api main.c, update the code to be compilable on Windows
Reviewers: asmith, zturner
Reviewed By: zturner
Subscribers: zturner
Differential Revision: https://reviews.llvm.org/D46440
llvm-svn: 331686
when it and the inferior process both have the same shared cache
(a conglomeration of all libraries at the same fixed address for
all processes), lldb will read data out of its own memory to speed
things up. The shared cache has a UUID, so lldb currently checks
that the UUID of its own shared cache matches that of the inferior.
This change adds one refinement to that -- it checks that the UUID
is the same and that the base address of the shared cache is the
same. And only uses its local shared cache if they are both identical.
This involved using a different style of SPI with dyld to get lldb's
shared cache load address, but it's not especially difficult.
One unattractive part of the change is that I'm using the real
underlying types of task_t and kern_return_t instead of picking
them up from mach/mach.h. The defines that get picked up there (a
lot from machine.h but others too) conflict with llvm/Support/MachO.h
even when I have mach.h included before our SafeMachO.h which
undefines most of the defines before including llvm/Support/MachO.h.
I'll need to augment the #undefs in SafeMachO.h to get this to
compile cleanly, but that'll be another day.
<rdar://problem/39868238>
llvm-svn: 331497
This is a change that only affects Swift and is NFC for the language
plugins on llvm.org. In Swift, we can have global variables with a
location such as DW_OP_addr <addr> DW_OP_deref. The DWARF expression
evaluator doesn't know how to apply a DW_OP_deref to a file address,
but at the very end we convert the file address into a load address.
This patch moves the file->load address conversion to right after the
result of the DW_OP_addr is pushed onto the stack so that a subsequent
DW_OP_deref (and potentially other operations) can be interpreted.
rdar://problem/39767528
Differential revision: https://reviews.llvm.org/D46362
llvm-svn: 331492
This patch restructures part of LLDB's testing configuration:
1. I moved the test dependencies up the chain so every dotest dependency
becomes a lit dependency as well. It wouldn't make sense for dotest to
have other dependencies when it's being run by lit. Lit on the other
hand can still specify extra dependencies.
2. I replaced as much generator expressions with variables as possible.
This is consistent with the rest of LLVM and doesn't break generators
that support multiple targets (MSVC, Xcode). This wasn't a problem
before, but now we need to expand the dotest arguments in the lit
configuration and there's only one test suite even with multiple
targets.
3. I moved lldb-dotest into it's own directory under utils since there's
no need anymore for it to located under `test/`.
Differential revision: https://reviews.llvm.org/D46334
llvm-svn: 331463
This is a change that only affects Swift and is NFC for the language
plugins on llvm.org. In Swift, we can have global variables with a
location such as DW_OP_addr <addr> DW_OP_deref. The DWARF expression
evaluator doesn't know how to apply a DW_OP_deref to a file address,
but at the very end we convert the file address into a load address.
This patch moves the file->load address conversion to right after the
result of the DW_OP_addr is pushed onto the stack so that a subsequent
DW_OP_deref (and potentially other operations) can be interpreted.
rdar://problem/39767528
Differential revision: https://reviews.llvm.org/D46362
llvm-svn: 331462
The function can only return in one of two ways: the Predicate value is
successfully set within the allotted time, or it isn't (the wait times
out). These states can be represented in the return value, and the extra
arg adds no value.
llvm-svn: 331458
Summary:
lldb-test already had the ability to dump all symbol information in a
module. This is interesting, but it can be too verbose, and it also does
not use the same APIs that lldb uses to query symbol information. The
last part is interesting to me now, because I am about to add DWARF v5
debug_names support, which needs to implement these APIs.
This patch adds a set of arguments to lldb-test, which modify it's
behavior from dumping all symbols to dumping only the requested
information:
- --find={function,namespace,type,variable} - search for the given
kind of objects.
- --name - the name to search for.
- --regex - whether to treat the "name" as a regular expression. This is
not available for all lookup types (we do not have the required APIs
for namespaces and types).
- --context - specifies the context, which can be used to restrict the
search. This argument takes a variable name (which must be defined and
be unique), and we then use the context that this variable is defined
in as the search context.
- --function-flags={auto,full,base,method,selector} - a set of flags to
further restrict the search for function symbols.
Together, these flags and their combinations cover the main SymbolFile
entry points which I will need to modify for the accelerator table
support, and so I plan to do most of the regression testing this way.
(I've also found this a useful tool for exploration of what the given
APIs are supposed to do.)
I add a couple of tests to demonstrate the usage of the usage of the
various options, and also an xfailed test which demonstrates a bug I
found while playing with this. The only requirement for these tests is
the presence of lld -- the should run on any platform which is able to
build lldb.
These tests use c++ code as input, but this isn't a requirement. It is also
possible to use IR, assembly or json to create the test module.
Reviewers: davide, zturner, asmith, JDevlieghere, clayborg, alexshap
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46318
llvm-svn: 331447
This change adds support for two types of Minidump CodeView records:
PDB70 (reference: https://crashpad.chromium.org/doxygen/structcrashpad_1_1CodeViewRecordPDB70.html)
This is by far the most common record type.
ELF BuildID (found in Breakpad/Crashpad generated minidumps)
This would set a proper UUID for placeholder modules, in turn enabling
an accurate match with local module images.
Differential Revision: https://reviews.llvm.org/D46292
llvm-svn: 331394
In case we are building with xml enabled, the GetMemoryRegionInfo
function will send extra packets to query te extended memory map, which
the tests were not expecting.
Add an expectation for this to the test. Right now, it's just a basic
one which pretends we don't support the extension, however, it would be
also interesting the add a test which verifies the extension-enabled
case.
I also noticed that the test does a pretty lousy job of validating the
returned memory region info, so I add a couple of extra assertions to
improve that.
llvm-svn: 331374
This brings the LLDB configuration closer to LLVM's and removes visual
clutter in the source code by removing the @brief commands from
comments.
This patch also reflows the paragraphs in all doxygen comments.
See also https://reviews.llvm.org/D46290.
Differential Revision: https://reviews.llvm.org/D46321
llvm-svn: 331373
The functions are unused, their comments are out of date with the
implementation, and the implementation is out of date with the rest of the code
base (it uses seconds(0) to mean infinite wait, whereas elsewhere we use the
Timeout class).
llvm-svn: 331350
if an experimental setting has been removed/is missing.
Add tests for the .experimental. settings behaviors -- that they correctly
forward through to the real setting if it has become a real setting,
that they don't generate errors when a settig has been removed.
As Pavel notes in https://reviews.llvm.org/D45348, the way I'm suppressing
errors in the setting is not completely correct - if any of the setting
path components include "experimental", a missing setting would be declared
a non-error. So
settings set target.experimental.setting-that-does-not-exist true
would not generate an error, which is correct. But as Pavel notes,
settings set setting-does-not-exist.experimental.run-stopped true
should generate an error because the unknown name occurs before the
"experimental". The amount of change to do this correctly hasn't
thrilled me, so I'm leaving this as-is for now.
<rdar://problem/39223054>
Differential Revision: https://reviews.llvm.org/D45348
llvm-svn: 331315
The lit site configuration for the test suite can contain generator
expressions such as $<TARGET_FILE:debugserver> that need to be
substituted.
llvm-svn: 331277
Displaying of global pointer variables is not working on arm64 linux
(pr37301).
I've moved this part into a separate test, so it can be xfailed
separately. I then move the "show-variables-with-process-available"
check before the "show-all-variables" command to presrve the intent of
checking that global variable caching works correctly. (I've verified
that the new arrangement still fails when I revert the fix from
r331230.)
llvm-svn: 331250
that takes a prefix string. This simplifies the implementation and
allows plugins such as the Swift plugin to supply different prefixes
for return and error variables.
rdar://problem/39299889
Differential Revision: https://reviews.llvm.org/D46088
llvm-svn: 331235
so it can be shared across multiple language plugins.
In a multi-language project it is counterintuitive to have a result
variables reuse numbers just because they are using a different
language plugin in LLDB (but not for example, when they are
Objective-C versus C++, since they are both handled by Clang).
This is NFC on llvm.org except for the Go plugin.
rdar://problem/39299889
Differential Revision: https://reviews.llvm.org/D46083
llvm-svn: 331234
This fixes a bug where
(lldb) target var g_ptr
would populate the global variables list with exactly one entry
because SymbolFileDWARF::ParseVariables() was invoked with a list of
DIEs pre-filtered by name, such that a subsequent call to
(lldb) fr var --show-globals
would only list that one variable, because CompileUnit::m_variables
was already initialized, fooling CompileUnit::GetVariableList().
CompileUnit::GetVariableList() grabs the *complete* list of variables
via (SymbolFileDWARF, ...)::ParseVariablesForContext and that still
calls CompileUnit::SetVariableList(variables) which acts as the
caching mechanism.
Differential Revision: https://reviews.llvm.org/D46220
llvm-svn: 331230
Multiple DW_TAG_compile_unit being indexed in a multithreaded way can request
reading of the same DW_TAG_partial_unit.
Unfortunately one cannot detect DWZ file ahead of time to disable such locking
overhead as DWARFCompileUnit::Extract does not read the first DIE which is the
only place one could find early enough if the DWARF file is using any
DW_TAG_partial_unit.
Differential revision: https://reviews.llvm.org/D40470
llvm-svn: 331229
This patch fixes an issue where we weren't looking for exact matches in the expression parser and also fixed the type lookup logic in the Module.cpp. Tests added to make sure we don't regress.
Differential Revision: https://reviews.llvm.org/D46128
llvm-svn: 331227
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
Code commonly checks if the parent DIE is DW_TAG_compile_unit.
But DW_TAG_partial_unit also acts as DW_TAG_compile_unit for DWZ
as DWZ is using DW_TAG_imported_unit only at the top unit level.
Differential revision: https://reviews.llvm.org/D40469
llvm-svn: 331194
ObjectFileELF assumes that code section has ".text" name. There is an
exception for kalimba toolchain that can use arbitrary names, but other
toolchains also could use arbitrary names for code sections. For
example, corert uses separate section for compiled managed code. As lldb
doesn't recognize such section it leads to problem with breakpoints on
arm, because debugger cannot determine instruction set (arm/thumb) and
uses incorrect breakpoint opcode that breaks program execution.
This change allows debugger to correctly handle such code sections. We
assume that section is a code section if it has SHF_EXECINSTR flag set
and has SHT_PROGBITS type.
Patch by Konstantin Baladurin <k.baladurin@partner.samsung.com>.
Differential Revision: https://reviews.llvm.org/D44998
llvm-svn: 331173
A typo in the patch (using syntax instead of m_syntax) resulted in the
normalization not working properly for windows filespecs when the syntax
was passed as host-native. This did not affect the unit tests, as all of
those pass an explicity syntax, but failed gloriously when running the
full test suite.
I also fix an expectation in an lldb-mi test, which was now failing
because it was expecting a path to be echoed verbatim, but we were now
normalizing it.
As a drive-by, this also fixes the default-in-fully-covered-switch
warning and removes an unused argument from the NeedsNormalization
function.
llvm-svn: 331172
Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed.
Differential Revision: https://reviews.llvm.org/D45977
llvm-svn: 331049
LLDB doesn't use this packet so we never hit this, but it looks like
some other projects talk to debugserver and are hitting an assert
(https://github.com/derekparker/delve/issues/1015).
We had an off by 1 in the accounting of the FPU structure sizes.
I added a test that basically just check that 'g' doesn't return
an error (currently it assert in debug builds). I didn't make
it an lldb-server test because it looks like lldb-server doesn't
implement the g packet.
llvm-svn: 331004
When I merged the 2 codepaths that return an OS type, I hade
checked that the places accepting 'iphoneos' would also accept
'ios', but then I got it backwards and return 'iphoneos'.
We use this value to build triples, and there 'iphoneos' is
invalid.
This also makes the test slightly simpler.
llvm-svn: 330877
source/Symbol/ClangASTContext.cpp:391:13: error: enumeration value 'HIP' not handled in switch [-Werror,-Wswitch]
switch (IK.getLanguage()) {
llvm-svn: 330823
Summary:
The new script to run the lldbtests as part of lit invokes each test by calling dotest.py, however, we cannot rely on the system to always correctly interpret the script as python causing the tests to be unresolved on windows (at least). To fix this, we need to make sure that the first parameter in the command line is the python executable itself.
In Makefile.rules, there are a number of windows specific definitions that rely on the HOST_OS being set as Windows_NT but the logic detecting the OS currently does not detect server versions of windows correctly. This change updates the logic to detect windows server as well.
Reviewers: asmith, labath, JDevlieghere, zturner
Reviewed By: JDevlieghere, zturner
Subscribers: zturner, llvm-commits
Differential Revision: https://reviews.llvm.org/D46020
llvm-svn: 330740
Summary:
In the magic test duplicator, we were making the decision whether to
create a test variant based on the compiler and the target platform.
This meant that the set of known tests was different for each test
configuration.
This patch makes the set of generated test variants static and handles
the skipping via runtime checks instead. This is more consistent with
how we do other test-skipping decision (e.g. for libc++ tests), and
makes it easier to expose the full set of tests to lit, which now does
not need to know anything about what things can potentially cause tests
to appear or disappear.
Reviewers: JDevlieghere, aprantl
Subscribers: eraman, lldb-commits
Differential Revision: https://reviews.llvm.org/D45949
llvm-svn: 330708
The default packet timeout of 1 second is a bit too small for these
tests, particularly as they are working in ack-mode, which means they
need to fit twice as many packets into the timeslot.
This does not seem to be a problem on the bots, but for some people
these tests are timing out regularly. I can't be sure increasing this
will solve their problem, but this does seem like a likely culprit.
llvm-svn: 330578
The current way that the lit configuration is generated for the LLDB
tests that run using dotest causes cmake to fail when using a generator
which supports multiple configurations (such as Visual Studio). The
failure is because file GENERATE will create a file *per possible
configuration* resulting in the same lit configuration file being
overwritten multiple times.
To fix the issue, we need to create a single lit file that is agnostic
of the configurations and can be used for any configuration.
Patch by: Stella Stamenova
Differential revision: https://reviews.llvm.org/D45918
llvm-svn: 330518
Previously, an attempt to read an unreadable address reported zeros.
Now, if DoReadMemory or DoWriteMemory encounters error then return 0
(bytes read or written) so that the error is reported to the user.
llvm.org/pr37190
llvm-svn: 330500
The isOverload() method needs to account for situations where the two
methods being compared don't have the same number of arguments.
rdar://problem/39542960
llvm-svn: 330450
It was failing because the modules names were coming out as
C:\Windows\System32/MSVCP120D.dll (last separator is a forward slash) on
windows.
There are two issues at play here:
- the first problem is that the paths in minidump were being parsed as a
host path. This meant that on posix systems the whole path was
interpreted as a file name.
- on windows the path was split into a directory-filename pair
correctly, but then when it was reconsituted, the last separator ended
up being a forward slash because SBFileSpec.fullpath was joining them
with '/' unconditionally.
I fix the first issue by parsing the minidump paths according to the
path syntax of the host which produced the dump, which should make the
test behavior on posix&windows identical. The last path will still be a
forward slash because of the second issue. We should probably fix the
"fullpath" property to do something smarter in the future.
llvm-svn: 330314
Normally, LLDB is creating a high-fidelity representation of a live
process, including a list of modules and sections, with the
associated memory address ranges. In order to build the module and
section map LLDB tries to locate the local module image (object file)
and will parse it.
This does not work for postmortem debugging scenarios where the crash
dump (minidump in this case) was captured on a different machine.
Fortunately the minidump format encodes enough information about
each module's memory range to allow us to create placeholder modules.
This enables most LLDB functionality involving address-to-module
translations.
Also, we may want to completly disable the search for matching
local object files if we load minidumps unless we can prove that the
local image matches the one from the crash origin.
(not part of this change, see: llvm.org/pr35193)
Example: Identify the module from a stack frame PC:
Before:
thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14
frame #0: 0x00164d14
frame #1: 0x00167c79
frame #2: 0x00167e6d
frame #3: 0x7510336a
frame #4: 0x77759882
frame #5: 0x77759855
After:
thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14
frame #0: 0x00164d14 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
frame #1: 0x00167c79 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
frame #2: 0x00167e6d C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
frame #3: 0x7510336a C:\Windows\SysWOW64\kernel32.dll
frame #4: 0x77759882 C:\Windows\SysWOW64\ntdll.dll
frame #5: 0x77759855 C:\Windows\SysWOW64\ntdll.dll
Example: target modules list
Before:
error: the target has no associated executable images
After:
[ 0] C:\Windows\System32\MSVCP120D.dll
[ 1] C:\Windows\SysWOW64\kernel32.dll
[ 2] C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
[ 3] C:\Windows\System32\MSVCR120D.dll
[ 4] C:\Windows\SysWOW64\KERNELBASE.dll
[ 5] C:\Windows\SysWOW64\ntdll.dll
NOTE: the minidump format also includes the debug info GUID, so we can
fill-in the module UUID from it, but this part was excluded from this change
to keep the changes simple (the LLDB UUID is hardcoded to be either 16 or
20 bytes, while the CodeView GUIDs are normally 24 bytes)
Differential Revision: https://reviews.llvm.org/D45700
llvm-svn: 330302
This is the first in what will hopefully become a series of patches to
replace the driver logic in dotest.py with LIT. The motivation for this
change is that there's no point in maintaining two driver
implementations. Since all of the LLVM projects are using lit, this is
the obvious choice.
Obviously the goal is maintain full compatibility with the functionality
offered by dotest. As such we won't be removing anything until that
point has been reached.
This patch is the initial attempt (referred to as v1) to run the lldb
test suite with lit. To do so we introduced a custom LLDB test format
that invokes dotest.py with a single test file.
Differential revision: https://reviews.llvm.org/D45333
llvm-svn: 330275
Summary:
If the remote stub sends a specific error message instead of just a E??
code, we can use this to display a more informative error message
instead of just the generic "unable to attach" message.
I write a test for this using the SB API.
On the console this will show up like:
(lldb) process attach ...
error: attach failed: <STUB-MESSAGE>
if the stub supports error messages, or:
error: attach failed: Error ??
if it doesn't.
Reviewers: jingham, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D45573
llvm-svn: 330247
That way we won't have to compile a new expression every time we want
dlopen a library.
<rdar://problem/32626584>
Differential Revision: https://reviews.llvm.org/D45703
llvm-svn: 330214
Summary:
The Args class is used in plenty of places besides the command
interpreter (e.g., anything requiring an argc+argv combo, such as when
launching a process), so it needs to be in a lower layer. Now that the
class has no external dependencies, it can be moved down to the Utility
module.
This removes the last (direct) dependency from the Host module to
Interpreter, so I remove the Interpreter module from Host's dependency
list.
Reviewers: zturner, jingham, davide
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D45480
llvm-svn: 330200
We don't really care about the order as this is a dictionary.
It should be more resilient to changes (adding/shuffling stats
around).
Pointed out by Jason Molenda in a post-commit review (thanks Jason).
llvm-svn: 330170
This patch by Greg Clayton drops the virtualization for DWARFPartialUnit.
The virtualization of DWARFUnit now matches more its LLVM counterpart.
DWZ patchset is going to be implementable without DWARFPartialUnit remapping.
https://reviews.llvm.org/D40474
This reverts commit 329423.
This reapplies commit r329305.
llvm-svn: 330084
This allows us to collect useful metrics about lldb debugging sessions.
I thought that an example would be better than a thousand words:
Process 19705 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
frame #0: 0x0000000100000fb4 blah`main at blah.c:3
1 int main(void) {
2 int a = 6;
-> 3 return 0;
4 }
(lldb) statistics enable
(lldb) frame var a
(int) a = 6
(lldb) expr a
(int) $1 = 6
(lldb) statistics disable
(lldb) statistics dump
Number of expr evaluation successes : 1
Number of expr evaluation failures : 0
Number of frame var successes : 1
Number of frame var failures : 0
Future improvements might include:
1. Passing a file, or implementing categories. The way this patch has
been implemented is generic enough to allow this to be extended
easily without breaking the grammar.
2. Adding an SBAPI and Python API for use in scripts.
Thanks to Jim Ingham for discussing the design with me.
<rdar://problem/36555975>
Differential Revision: https://reviews.llvm.org/D45547
llvm-svn: 330043
Many IDEs set breakpoints using absolute paths and this causes problems when the full path of the source file path doesn't match what is in the debug info. This can be due to different build systems and do or do not resolve symlinks. This patch allows relative breakpoint to be set correctly without needing to do any target.source-map tricks. If IDEs want to, they can send down relative paths like:
./main.c
./src/main.c
src/main.c
foo/bar/src/main.c
I used the breakpoint resolver to match on the file basename and then we weed out anything whose relative paths don't match. This will be a huge improvement for IDEs as they can specify as much of a relative path as desired to uniquely identify a source file in the current project.
Differential Revision: https://reviews.llvm.org/D45592
llvm-svn: 330028
When we're dealing with virtual (memory) threads created by the OS
plugins, there's no guarantee that the real thread and the backing
thread share a protocol ID. Instead, we should iterate over the memory
threads to find the virtual thread that is backed by the current real
thread.
Differential revision: https://reviews.llvm.org/D45497
rdar://36485830
The original revision (r329891) was reverted because the associated
tests ran into a deadlock on the Linux bots. That problem was resolved
by r330002.
llvm-svn: 330005
Summary:
When performing a synchronous resume, the API mutex is held until the
process is stopped. This is fine, except for when the OS plugins are processing
an event before the main thread is aware of it, in which case we end up with a
deadlock because in the internal thread we acquire a resource lock first, and
then wait for the API lock, while in the main thread we do the opposite, we
already hold the API mutex but are now waiting for the event mutex to handle
the event.
This patch fixes this by relaxing the need for the API lock in the OS plugins.
We can get away with this because we now this code is executed in the main
thread. As stated in the comment above, we just want to ensure nobody else
messes with the API while we're making a change. In theory it's possible that
the main thread would release the lock while we're executing the function, but
prevent this would require a more structural solution (which we want, but do
not have today).
The same workaround was already present, but this patch generalizes it to the
whole file.
This will allow me to re-land r329891.
Reviewers: clayborg, jingham, labath
Subscribers: llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D45586
llvm-svn: 330002
When we're dealing with virtual (memory) threads created by the OS
plugins, there's no guarantee that the real thread and the backing
thread share a protocol ID. Instead, we should iterate over the memory
threads to find the virtual thread that is backed by the current real
thread.
Differential revision: https://reviews.llvm.org/D45497
rdar://36485830
llvm-svn: 329891
Summary:
With the upstream implementation of dsymutil containing almost all
functionality from the one shipped with Xcode, we want to use the
in-tree version for running the test suite.
This will also allow us to re-enable TestUnicodeSymbols which was
failing because of the discrepancy in how Unicode symbols were hashed in
lldb and older versions of dsymutil.
Reviewers: aprantl, davide, jingham, labath
Subscribers: mgorny, llvm-commits, lldb-commits
Differential Revision: https://reviews.llvm.org/D45518
llvm-svn: 329889
There are plenty of ways attaching can go wrong. Having the server
report the exact error means we can give better feedback to the user.
(This patch does not do the second part, it only makes sure the
information is sent from the server.)
Triggering all possible error conditions in a test would prove
challenging, but there is one error that is very easy to reproduce
(attempting to attach while debugging), so I write a test based on that.
The test immediately exposed a bug where the m_send_error_strings field
was being used uninitialized (so it was sometimes true from the get-go),
so I fix that as well.
llvm-svn: 329803
LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in
HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the
default macro instead of a reinvented one.
See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
No intended behavior change.
llvm-svn: 329697
It looks like we introduced isprint8 way back in r169417 to be used on
getopt's short_options, which we sometimes set to values which are out
of range for normal chars to indicate options with no short form.
However, this is not how the function is used in the Args class, where
we explicitly process a string character by character.
This removes the last external dependency from the Args class.
llvm-svn: 329682
These are not used anywhere in the Args class. They should have been
moved as a part of r327110 (Moving Option parsing from Args to Options),
but I did not notice them then.
This does not affect the layering in any way, but in makes sense for the
structs to be defined in the near the code that uses them.
llvm-svn: 329679
Summary:
The idea behind this is to move the functionality which depend on other lldb
classes into a separate class. This way, the Args class can be turned
into a lightweight arc+argv wrapper and moved into the lower lldb
layers.
Reviewers: jingham, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D44306
llvm-svn: 329677
The reverted commit changed DWARFUnit from https://reviews.llvm.org/D40466 and
https://reviews.llvm.org/D42892 that was prepared for DWARFPartialUnit and
made from it a superclass for DWARFTypeUnit. DWARFUnit's intention was:
DWARFUnit->DWARFSomeNameUnit->DWARFCompileUnit
DWARFUnit->DWARFSomeNameUnit->DWARFTypeUnit
DWARFUnit->DWARFPartialUnit
Discussed at: https://reviews.llvm.org/D45170
This reverts commit r329305.
llvm-svn: 329423
Summary:
In one of the 2 places the LC_BUILD_VERSION load command is handled, there
is a bug preventing us from actually handling them (the address where to
read the load command was not updated). This patch factors reading the
deployment target load commands into a helper and adds testing for the 2
code paths calling the helper.
The testing is a little bit complicated because the only times those load
commands matter is when debugging a simulator process. I added a new
decorator to check that a specific SDK is available. The actual testing was
fairly easy once I knew how to run a simulated process.
Reviewers: jasonmolenda, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D45298
llvm-svn: 329374
Many things that were in DWARFCompileUnit actually need to be in DWARFUnit. This patch moves all DWARFUnit specific things over into DWARFUnit and fixes the layering. This is in preparation for adding DWARFTypeUnit for the .debug_types patch.
Differential Revision: https://reviews.llvm.org/D45170
llvm-svn: 329305
After removing it, I got a couple of compile errors because we were
missing some symbols (SIGKILL and such), as their definitions were not
transitively included anymore. I fix this by including csignal from
PosixApi.h, as it's windows version provides a stub definitions of these
symbols. This should make the result of #including PosixApi.h more
consistent across platforms (although in the long run, we should just
get rid of this header).
llvm-svn: 329296
This is a combination stand alone BSD archive tool that can dump BSD archives:
% bsd.py /path/to/foo.a
Search archives for an object file:
% bsd.py --object foo.o bar.a
Dump the symbol definitions found in the __.SYMDEF objects:
% bsd.py --symdef bar.a
Find symbols by name that are listed in the __.SYMDEF objects:
% bsd.py --symbol _Z123 bar.a
Extract objects from BSD archives:
% bsd.py --object foo.o bar.a --extract
% bsd.py --object foo.o bar.a --extract --outfile /tmp/foo.o
% bsd.py --object foo.o bar.a --extract --mtime 0x1234556
It also has installs a new LLDB command line command when imported into LLDB:
(lldb) command script import ~/Dropbox/bin/bsd.py
The "verify-debug-map-objects" command has been installed, type "help verify-debug-map-objects" for detailed help.
(lldb) verify-debug-map-objects a.out
This will iterate through all object files and verify the modification times match for any .o files, it will verify any .o files from BSD archives are found and have matching modification times and print out errors if any are found.
llvm-svn: 328990
Remove Scalar::Cast.
It was noted on the list that this method is unused. So, this patch
removes it.
Fix Scalar::Promote for most integer types
This fixes promotion of most integer types (128- and 256-bit types are
handled in a subsequent patch) to floating-point types. Previously
promotion was done bitwise, where value preservation is correct.
Fix Scalar::Promote for 128- and 256-bit integer types
This patch fixes the behavior of Scalar::Promote when trying to
perform a binary operation involving a 128- or 256-bit integer type
and a floating-point type. Now, the integer is cast to the floating
point type for the operation.
Patch by Tom Tromey!
Differential Revision: https://reviews.llvm.org/D44907
llvm-svn: 328985
Summary:
We would fail to resolve (and thus display the value of) any
templated type which contained a template template argument even
though we don't really use template arguments.
This patch adds minimal support for template template arguments,
but I doubt we need any more than that.
Reviewers: clayborg, jingham
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D44613
llvm-svn: 328984
These functions were unused as everyone just went straight for the
direct operations on the register context. In fact, the
Save/RestoreAllRegisters actually appear to be wrong (inverted). Thanks
to Tatyana for pointing this out.
These functions are not very useful now that we can guarantee that each
thread always contains a valid register context, so I just delete them.
llvm-svn: 328770
Summary:
When a MIG routine returns KERN_FAILURE, the demux function will release any OOL resources like ports. In this case, task_port and thread_port will be released twice, potentially resulting in use after free of the ports.
I don't think we can test this in any useful way
rdar://problem/37331387
Reviewers: jasonmolenda
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D45011
llvm-svn: 328761
Summary:
We've had a mismatch in the checksum computation between the sender and
receiver. The sender computed the payload checksum using the wire
encoding of the packet, while the receiver did this after expanding
un-escaping and expanding run-length-encoded sequences. This resulted in
communication breakdown if packets using these feature were sent in the
ack mode.
Normally, this did not cause any issues since the only packet we send in
the ack-mode is the QStartNoAckMode packet, but I ran into this when
debugging the lldb-server tests which (for better or worse) don't use
this mode.
According to the gdb-remote documentation "The two-digit checksum is computed as
the modulo 256 sum of all characters between the leading ‘$’ and the
trailing ‘#’", it seems that our sender is doing the right thing here.
Therefore, I fix the receiver the match the sender behavior and add a
test.
With this bug fixed, we can see that lldb-server is sending a stop-reply
after receiving the "k" in the same way as debugserver does (but we
weren't detecting this because at that point the connection was dead
already). I fix that expectation as well.
Reviewers: clayborg, jasonmolenda
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D44922
llvm-svn: 328693
When importing C++ methods into clang AST nodes from the DWARF symbol
table, preserve the DW_AT_linkage_name and use it as the linker
("asm") name for the symbol.
Concretely, this enables `expression` to call into names that use the
GNU `abi_tag` extension, and enables lldb to call into code using
std::string or std::list from recent versions of libstdc++. See
https://bugs.llvm.org/show_bug.cgi?id=35310 . It also seems broadly
more robust than relying on the DWARF->clang->codegen pipeline to
roundtrip properly, but I'm not immediately aware of any other cases
in which it makes a difference.
Patch by Nelson Elhage!
Differential Revision: https://reviews.llvm.org/D40283
llvm-svn: 328658
The first issue was that the test was capturing the "before" disassembly
before launching, and the "after" after. This is a problem because some
of the disassembly will change after we know the load address (e.g. PCs
in call instructions). I fix this by capturing both disassemblies with
the process running.
The second issue was that the refactor in r328488 accidentaly changed
the meaning of the test, as it was no longer disassembling the function
which contained the breakpoint.
While inside, I also modernize the test to use
lldbutil.run_to_source_breakpoint and prevent debug-info replication.
llvm-svn: 328504
- close_fds is not compatible with stdin/out redirection on windows. I
just remove it, as this is not required for correct operation.
- the command string was assuming a posix shell. I rewrite the Popen
invocation to avoid the need for passing the arguments through a shell.
llvm-svn: 328489
Summary:
TestExprsChar.py
Char is unsigned char by default in PowerPC.
TestDisassembleBreakpoint.py
Modify disassemble testcase to consider multiple architectures.
TestThreadJump.py
Jumping directly to the return line on PowerPC architecture dos not
means returning the value that is seen on the code. The last test fails,
because it needs the execution of some assembly in the beginning of the
function. Avoiding this test for this architecture.
TestEhFrameUnwind.py
Implement func for ppc64le test case.
TestWatchLocation.py
TestStepOverWatchpoint.py
PowerPC currently supports only one H/W watchpoint.
TestDisassembleRawData.py
Add PowerPC opcode and instruction for disassemble testcase.
Reviewers: labath
Reviewed By: labath
Subscribers: davide, labath, alexandreyy, lldb-commits, luporl, lbianc
Differential Revision: https://reviews.llvm.org/D44472
Patch by Alexandre Yukio Yamashita <alexandre.yamashita@eldorado.org.br>.
llvm-svn: 328488
Summary: PPC64's auxvec has a special key that must be ignored.
Reviewers: clayborg, labath
Reviewed By: clayborg, labath
Subscribers: alexandreyy, lbianc
Differential Revision: https://reviews.llvm.org/D43771
Patch by Leandro Lupori <leandro.lupori@gmail.com>.
llvm-svn: 328486
Summary:
First attempt at landing D42145 was reverted because it caused test
failures on some android devices. It turned out this was because these
devices had vdso modules with differing physical and virtual addresses.
This was not caught earlier because all of the modules in our tests
either lack physical addresses or have them identical to virtual ones.
In the discussion on the patch, we came to the conclusion that in the
scenario where we are merely setting a load address of a module (for
example from a dynamic loader plugin), we should always use virtual
addresses (i.e., preserve status quo). This patch adds a test to make
sure we don't regress in that direction.
Reviewers: owenpshaw
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D44738
llvm-svn: 328485
This one will be used to print statistics about lldb sessions
(including, e.g. number of expression evaluation succeeded or
failed). I decided to commit the skeleton first so that we have
a clean reference on how a command should be implemented.
My future commits are going to populate this command and test
it.
<rdar://problem/36555975>
llvm-svn: 328378
It wasn't even registered.
(lldb) apropos args
No commands found pertaining to 'args'. Try 'help' to see
a complete list of debugger commands.
llvm-svn: 328370
Some PDB Symbols don't have line information. Use the section contributions to determine their compiland.
This is useful to determine the parent compiland for PDBSymbolTypeData, i.e. variables.
llvm-svn: 328232
- postmortem tests: make sure the core files are created in the build
folder
- TestSourceManager: copy the .c file into the build dir before
modifying it
- TestLogging: create log files in the build folder
After these changes I get a clean test run (on linux) even if I set the
source tree to be read only. It's possible some of the skipped/xfailed
tests are still creating files in the source tree, but at the moment, I
don't have plans to go hunting for those.
llvm-svn: 328106
As suggested by Pavel on lldb-commits. Originally I picked os.system
because it was so much more simple than the subprocess module, but that
no longer holds true after yesterday's hack in r328020. This is what it
should've been in the first place.
Differential revision: https://reviews.llvm.org/D44728
llvm-svn: 328089
The issue was that the ASTDumper was being passed a null pointer
(because we did not create any declaration for the operator==). The
crash was in logging code, so it only manifested it self if you ran the
tests with logging enabled (like our bots do).
Given that this is logging code and the rest of the debugger is fine
with the declaration being null, I just make sure the logging code can
handle it as well. Right now I just do the null check in
ClangExpressionDeclMap, but if the ASTDumper class is meant to be a
debugging/logging aid, then it might be a good idea move the check
inside the class itself.
llvm-svn: 328088
- use more goodies from Makefile.rules to correctly build a 32-bit
binary.
- avoid hardcoding typeof(nil) in the test.
This should partially fix the linux bot. There is still one assertion
failure remaining, which I'll have to investigate separately, as I am
not experiencing it locally.
llvm-svn: 328083
New tests should run the make syntax voodoo $@ and $<
instead of hardcoding the names. We should also document
how to write one, it's on my list.
llvm-svn: 328062
Instead of applying the sledgehammer of refusing to insert any
C++ symbol in the ASTContext, try to validate the decl if what
we have is an operator. There was other code in lldb which was
responsible for this, just not really exposed (or used) in this
codepath. Also, add a better/more comprehensive test.
<rdar://problem/35645893>
llvm-svn: 328025
If we don't wrap arguments to the wrapper in single quotes, combined
arguments, for example for -E, don't reach dotest.py as a unit but as
separate arguments, causing the latter to fail.
llvm-svn: 328020
While trying to use this header I noticed that it is not in the include
folder. Move it to there and update all #includes to reference that file
correctly.
llvm-svn: 327996
Summary:
When running on an architecture other than x86_64, the
target.ConnectRemote() part of the test may add platform information to
the target triple.
It was observed that this happens at Process::CompleteAttach() method,
after the platform_sp->IsCompatibleArchitecture() check fails.
This method then calls platform_sp->GetPlatformForArchitecture(), that
on a Linux machine ends up returning a generic Linux platform, that then
ends up getting added to the original target architecture.
Reviewers: clayborg, labath, jasonmolenda
Reviewed By: labath
Subscribers: alexandreyy, lbianc
Differential Revision: https://reviews.llvm.org/D44022
Patch by Leandro Lupori <leandro.lupori@gmail.com>.
llvm-svn: 327981
Summary:
- Fix test jump for powerpc64le
Jumping directly to the return line on power architecture dos not means
returning the value that is seen on the code. The last test fails, because
it needs the execution of some assembly in the beginning of the function.
Avoiding this test for this architecture.
- Avoid evaluate environ variable name on Linux
On Linux the Symbol environ conflicts with another variable, then in
order to avoid it, this test was moved into a specific test, which is not
supported if the OS is Linux.
- Added PPC64le as MIPS behavior
Checking the disassembler output, on PPC64le machines behaves as MPIS.
Added method to identify PPC64le architecture and checking it when
disassembling instructions in the test case.
Reviewers: labath
Reviewed By: labath
Subscribers: clayborg, labath, luporl, alexandreyy, sdardis, ki.stfu, arichardson
Differential Revision: https://reviews.llvm.org/D44101
Patch by Leonardo Bianconi <leonardo.bianconi@eldorado.org.br>.
llvm-svn: 327977
The difference between this and the previous patch is that now we use
ELF physical addresses only for loading objects into the target (and the
rest of the module load address logic still uses virtual addresses).
Summary:
When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup.
- Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address.
- Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications
- Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region
Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: llvm-commits, arichardson, emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42145
Patch by Owen Shaw <llvm@owenpshaw.net>.
llvm-svn: 327970
in to debugserver; my re-addition resulted in duplicated
symbols. Remove my added SocketAddress.cpp, and change the
original one to also be included for the debugserver-mini target.
llvm-svn: 327918
the debugserver-mini target in debugserver. Add a new plist
which needs to be installed for debugserver-mini.
<rdar://problem/36751222>
llvm-svn: 327915
Now the codebase can use the DWARFUnit superclass. It will make it later
seamlessly work also with DWARFPartialUnit for DWZ.
This patch is only a search-and-replace easily undone, nothing interesting
in it.
Differential revision: https://reviews.llvm.org/D42892
llvm-svn: 327810
DW_TAG_partial_unit for DWZ can be then presented by DWARFPartialUnit also
inherited from DWARFUnit.
Differential revision: https://reviews.llvm.org/D40466
llvm-svn: 327809
Summary:
When in a gmodules-like debugging scenario, you can have a parent decl context
that gets imported from an external AST. When this happens, we must be careful
to complete this type before adding children to it, otherwise it sometimes
results in a crash.
Reviewers: clayborg, jingham
Subscribers: aprantl, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D43592
llvm-svn: 327750
Summary:
This patch implements a unified way of cleaning the build folder of each
test. This is done by completely removing the build folder before each
test, in the respective setUp() method. Previously, we were using a
combination of several methods, each with it's own drawbacks:
- nuking the entire build tree before running dotest: the issue here is
that this did not take place if you ran dotest manually
- running "make clean" before the main "make" target: this relied on the
clean command being correctly implemented. This was usually true, but
not always.
- for files which were not produced by make, each python file was
responsible for ensuring their deleting, using a variety of methods.
With this approach, the previous methods become redundant. I remove the
first two, since they are centralized. For the other various bits of
clean-up code in python files, I indend to delete it when I come
across it.
Reviewers: aprantl
Subscribers: emaste, ki.stfu, mgorny, eraman, lldb-commits
Differential Revision: https://reviews.llvm.org/D44526
llvm-svn: 327703
are installed
Instead of building debugserver when building lldb, I'd rather pass
LLDB_CODESIGN_IDENTITY="" to cmake and use the one already on my system.
However, on one of my machines I only have the CommandLineTools installed, and
so the hardcoded path to the system debugserver does not work for me.
Additionally, we should verify the LLDB framework exists on the machine before
trying to set the path to debugserver. This allows us to warn the user at
configure time that a system debugserver can't be found if they choose not to
build it themselves.
Patch by Alex Langford!
Differential Revision: https://reviews.llvm.org/D44507
llvm-svn: 327691
This test started failing after r327625. The cause seems difference in the
treatment of relative --stdin paths between MacOS (debugserver?) and linux
(lldb-server?). Linux treats this as relative to the debuggers PWD, while MacOS
as relative to (I think) the future PWD of the launched process.
This fixes the issue by using absolute paths, which should work everywhere, but
we should probably unify this path handling as well. I'll ask around about what
is the expected behavior here.
llvm-svn: 327633
Summary:
The changes here fall into several categories.
- some tests were redirecting inferior stdout/err to a file. For these I
make sure we use an absolute path for the file. I also create a
lldbutil.read_file_on_target helper function to encapsulate the
differences between reading a file locally and remotely.
- some tests were redirecting the pexpect I/O into a file. For these I
use a python StringIO object to avoid creating a file altogether.
- the TestSettings inferior was creating a file. Here, I make sure the
inferior is launched with pwd=build-dir so that the files end up
created there.
- lldb-mi --log (used by some tests) creates a log file in PWD without
the ability say differently. To make this work I make sure to run
lldb-mi with PWD=build_dir. This in turn necessitated a couple of
changes in other lldb-mi tests, which were using relative paths to
access the source tree.
Reviewers: aprantl
Subscribers: ki.stfu, mehdi_amini, lldb-commits
Differential Revision: https://reviews.llvm.org/D44159
llvm-svn: 327625
When using:
(lldb) settings set target.source-map ./ /path/to/source
LLDB would fail to set a source file and line breakpoint with:
(lldb) breakpoint set --file /path/to/source/main.c --line 2
Because code in the target was undoing the remapping of "/path/to/source/main.c" to "./main.c" and then it would resolve this path, which would append the current working directory to the path. We don't want to resolve paths that we unmap.
Test case added.
Differential Revision: https://reviews.llvm.org/D44502
llvm-svn: 327600
Until we have a better story for putting commands and check lines
in the same file (they're currently ignored), it seems that inline
tests are actually more concise and easier to understand.
Too bad we have still some python boilerplate, but that's not
really substantial so we can live with it.
Thanks to Fred for pointing out and Jim for explaining me how
to use the inline test format.
<rdar://problem/34806516>
llvm-svn: 327592
Before the patch:
(lldb) frame var emptyDictionary
(__NSDictionary0 *) emptyDictionary = 0x0000000100304420
After:
(lldb) frame var emptyDictionary
(__NSDictionary0 *) emptyDictionary = 0x0000000100304420 0 key/value pairs
There's nothing much else we can do, as this is always empty by
definition.
<rdar://problem/34806516>
llvm-svn: 327587
This is a first pass at removing some lldb-mi tests which have been
xfailed and unmaintained for a while. We have open PRs for most of these
tests already. I've opened up the following additional PRs:
llvm.org/PR36739 - lldb-mi driver exits properly
llvm.org/PR36740 - lldb-mi -gdb-set and -gdb-show
llvm.org/PR36741 - lldb-mi -symbol-xxx
The motivation here is to address timeout and pexpect-related issues in
the test suite. This was discussed on lldb-dev in the thread: "increase
timeout for tests?".
After this change, the lldb-mi tests seem to be in better health (on
Darwin at least). I consistently get:
$ ./bin/llvm-dotest -p TestMi
===================
Test Result Summary
===================
Test Methods: 101
Reruns: 0
Success: 88
Expected Failure: 0
Failure: 0
Error: 0
Exceptional Exit: 0
Unexpected Success: 0
Skip: 13
Timeout: 0
Expected Timeout: 0
llvm-svn: 327552
This renames llvm-dotest to lldb-dotest and makes it a custom target so
you can run `ninja lldb-dotest` to rebuild whatever is necessary before
rerunning the tests.
Differential revision: https://reviews.llvm.org/D44473
llvm-svn: 327519
The OS plugins might have updated the thread list after a core file has
been loaded. The physical thread in the core file may no longer be the
one that should be selected. Hence we should run the thread selection
logic after loading the core.
Differential revision: https://reviews.llvm.org/D44139
llvm-svn: 327501
Summary:
To make this build work, I needed to add detection code for the pthread
library. This is necessary, because we have direct calls to these
libraries (instead of going through llvm) and in the standalone build we
cannot rely on llvm to detect these for us. In a standalone non-dylib
build this was accidentaly working because these libraries were pulled
in as an interface dependency of the .a files, but in a dylib build
these are no longer part of the link interface, and so we need to add
them explicitly.
Reviewers: krytarowski, zturner
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D44379
llvm-svn: 327490
The expression-hits tracking logic is not available on any platform. The
reason this tests happens to pass on some platforms is that the test is
written poorly -- it relies on the fact that post-main cleanup code will
write to the stack memory once occupied by the watched variable, but
this is not the case everywhere (e.g. linux glibc does not seem to do
this, but android's bionic library does).
llvm-svn: 327483
Summary:
The types for the compiland's children are parsed when parsing types for a PDB compiland. Global types also need to be parsed but unfortunately PDBs do not have compiland information about each global type. So we parse them all on the first call to ParseTypes.
If a sc.function is provided then parse the types for that function. Otherwise parse the types for the overall sc.comp_unit.
The ParseTypes method can be very slow if a program has a long list of compile units containing needed modules. Debugging clang-cl with lldb will show the problem.
Reviewers: zturner, rnk, lldb-commits
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44253
llvm-svn: 327473
clang-3.8 complains that constructor for '...' must explicitly
initialize the const member. Newer clangs and gcc seem to be fine with
this, but explicitly initializing the member does not hurt.
llvm-svn: 327380
Typical example, illformed comparisons (operator== where LHS and
RHS are not compatible). If a symbol matched `operator==` in any
of the object files lldb inserted a generic function declaration
in the ASTContext on which Sema operates. Maintaining the AST
context invariants is fairly tricky and sometimes resulted in
crashes inside clang (or assertions hit).
The real reason why this feature exists in the first place is
that of allowing users to do something like:
(lldb) call printf("patatino")
even if the debug informations for printf() is not available.
Eventually, we might reconsider this feature in its
entirety, but for now we can't remove it as it would break
a bunch of users. Instead, try to limit it to non-C++ symbols,
where getting the invariants right is hopefully easier.
Now you can't do in lldb anymore
(lldb) call _Zsomethingsomething(1,2,3)
but that doesn't seem to be such a big loss.
<rdar://problem/35645893>
llvm-svn: 327356
This is a more principled approach to disabling Spotlight .dSYM
lookups while running the testsuite, most importantly it also works
for the LIT-based tests, which I overlooked in my initial fix
(renaming the test build dir to lldb-tests.noindex).
Differential Revision: https://reviews.llvm.org/D44342
llvm-svn: 327330
This reverts commit r327318. It breaks the Xcode and CMake Darwin
builders:
clang: error: no such file or directory:
'.../source/Plugins/Architecture/PPC64/ArchitecturePPC64.cpp'
clang: error: no input files
More details are in https://reviews.llvm.org/D42582.
llvm-svn: 327327
Summary:
r327219 adds wrappers to sort which shuffle the container before sorting.
This causes lldb bots to break as the call to sort is now ambiguous:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-buildserver/builds/20725/steps/ninja%20build%20local/logs/stdio
So we need use llvm::sort instead of sort to avoid ambiguity with std::sort.
Note: This patch is just to unbreak the bots. I plan to have subsequent patches which will convert all
calls to std::sort to llvm::sort.
Reviewers: RKSimon, k8stone, jingham, labath, zturner
Subscribers: andreadb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D44354
llvm-svn: 327224
I want to extend the properties on ModuleList to also contain other
more general settings and renaming the settings category to symbols
seems to be the least bad of choices.
llvm-svn: 327193
The test I added in r327110 is failing on windows because of "import
pexpect". However, this import is no longer necessary as these tests
don't use pexpect anymore.
In fact, it seems that all TestCompletion tests are passing on windows
after this, so I enable all of them.
llvm-svn: 327133
Summary:
Besides being superfluous, this double merging was actually wrong and
causing some sections to be added twice. The reason for that was that
the code assumes section IDs are unique in the section list, but this is
only true if all sections in the list come from the same object file.
Reviewers: fjricci, jankratochvil
Subscribers: emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D44157
llvm-svn: 327123
Summary:
The args class is used in plenty of places (a lot of them in the lower lldb
layers) for representing a list of arguments, and most of these places don't
care about option parsing. Moving the option parsing out of the class removes
the largest external dependency (there are a couple more, but these are in
static functions), and brings us closer to being able to move it to the
Utility module).
The new home for these functions is the Options class, which was already used
as an argument to the parse calls, so this just inverts the dependency between
the two.
The functions are themselves are mainly just copied -- the biggest functional
change I've made to them is to avoid modifying the input Args argument (getopt
likes to permute the argument vector), as it was weird to have another class
reorder the entries in Args class. So now the functions don't modify the input
arguments, and (for those where it makes sense) return a new Args vector
instead. I've also made the addition of a "fake arg0" (required for getopt
compatibility) an implementation detail rather than a part of interface.
While doing that I noticed that ParseForCompletion function was recording the
option indexes in the shuffled vector, but then the consumer was looking up the
entries in the unshuffled one. This manifested itself as us not being able to
complete "watchpoint set variable foo --" (because getopt would move "foo" to
the end). Surprisingly all other completions (e.g. "watchpoint set variable foo
--w") were not affected by this. However, I couldn't find a comprehensive test
for command argument completion, so I consolidated the existing tests and added
a bunch of new ones.
Reviewers: davide, jingham, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D43837
llvm-svn: 327110
stuff. Activate it when an internal SDK is selected. Update the name of
the LDFLAGS to match the rest of the settings. Update the default arch for
ios builds.
llvm-svn: 327095
There is a mailing list discussion re: r325927 about why this test fails
in the dsym variant. I've marked it skipped for now, until the issue is
resolved.
llvm-svn: 327089
1. Link against libpmenergy and pmsample unconditionally. It is available on
macOS 10.10 ("Yosemite") and newer. We're already linking against libcompression
unconditionally which is only available on macOS 10.11 & newer.
2. Change a few "sdk=macosx.internal"'s to sdk=macosx.
3. Clean up a few places where libcompression was being enabled inconsistently.
Note: the -DLLDB_ENERGY define is only set when building against the macosx.internal
SDK; it includes a header file that is not public. We link against the dylibs
unconditionally for simplicity.
llvm-svn: 327084
The test "test_fp_special_purpose_register_read" in TestRegisters.py
fails on Darwin machines configured to use an out-of-tree debugserver.
The error message is: 'register read ftag' returns expected result, got
'ftag = 0x80'. This indicates that the debugserver in use is too old.
This commit introduces a decorator which can be used to skip tests which
rely on having a just-built debugserver. This resolves the issue:
$ ./bin/llvm-dotest -p TestRegisters.py -v
1 out of 617 test suites processed - TestRegisters.py
Test Methods: 7
Success: 6
Skip: 1
...
llvm-svn: 327052
These were removed in r309021 in what looks like an accidentally
committed change. This brings them back.
I also rename the header component to lldb-headers (instead of
lldb_headers) to match the llvm style and add a special
install-lldb-headers target, which installs just the headers.
llvm-svn: 327016
Summary:
On PPC64, the tested functions were being entered through their local entry point, while the tests expected the program to stop at the function start address, that, for PPC64, corresponds to the global entry point.
To fix the issue, the test program was modified to call the functions to be tested through function pointers, which, on PPC64, force the calls through the global entry point, while not affecting the test on other platforms.
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: alexandreyy, lbianc
Differential Revision: https://reviews.llvm.org/D43768
Patch by Leandro Lupori <leandro.lupori@gmail.com>.
llvm-svn: 327013
There's now a test using llvm-objcopy in lit/.
This doesn't fail on the bot(s) because `llvm-objcopy` is probably
already available there, but if you get a fresh checkout and run
`ninja check-lldb` you'll observe the failure as it's not tracking
the dependency correctly. This fixes the problem on my machine,
and probably everywhere else.
llvm-svn: 326919
Summary:
- Complete element type of PDBSymbolTypeArray.
- Add a test to check types of multi-dimensional array and pointers with CVR.
Reviewers: zturner, rnk, lldb-commits
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44167
llvm-svn: 326859
Test that "lldb-mi --interpreter" can interpret "target list" CLI command.
Patch by Alex Polyakov!
Differential Revision: https://reviews.llvm.org/D44040
llvm-svn: 326847
Summary:
The test was failing in remote debugging scenario with windows as a host
as cmd.exe is not able to parse the complicated shell commands in the
Makefile.
The test seemed like a perfect candidate for a more focused testing
approach, so I have rewritten in on top of lldb-test's module-sections
functionality. The slight gotcha there was that the
Module::GetSectionList does not include the sections from the symbol
file until someone manually calls Module::GetSymbolVendor. Normally,
this is not an issue, because someone will have initialized the symbol
vendor by the time anyone starts looking at the sections. However, when
all one this is dump the section list, we run into this problem.
I've tried making this behavior more automatic, but it turns out it's
not that easy, so for now, I just manually initialize the Symbol Vendor
before dumping out the sections in lldb-test.
Reviewers: jankratochvil
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D42914
llvm-svn: 326805
Summary:
In an effort to understand the function's operation, I've split it into logical
pieces. Parsing of a single segment is moved to a separate function (and the
parsing state that is carried from one segment to another is explicitly
captured in the SegmentParsingContext object). I've also extracted some pieces
of code which were already standalone (validation of the segment load command,
determining the section type, determining segment permissions) into
separate functions.
Parsing of a single section within the segment should probably also be a
separate function, but I've left that for a separate patch.
This patch is intended to be NFC.
Reviewers: clayborg, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D44074
llvm-svn: 326791
Summary:
- reg_nums were missing the end marker entry
- marked FP test to be skipped for ppc64
Reviewers: labath, clayborg
Reviewed By: labath, clayborg
Subscribers: alexandreyy, lbianc, nemanjai, kbarton
Differential Revision: https://reviews.llvm.org/D43767
Patch by Leandro Lupori <leandro.lupori@gmail.com>
llvm-svn: 326775
were originally written by Chris Bieneman, they've undergone a
number of changes since then.
Also including the debugserver bridgeos support, another arm
environment that runs Darwin akin to ios. These codepaths are
activated when running in a bridgeos environment which we're not
set up to test today.
There's additional (small) lldb changes to handle bridgeos binaries
that still need to be merged up.
Tested on a darwin system with avx512 hardware and without.
<rdar://problem/36424951>
llvm-svn: 326756
LLDB.framework to point to the build directory where it is expected by
the top-level CMakeLists.txt.
This should be a no-op in any other configurations.
rdar://problem/38005302
llvm-svn: 326743
These tests fail with a relatively frequently on Darwin machines with
errors such as:
File ".../lldb/third_party/Python/module/pexpect-2.4/pexpect.py", line 1444, in expect_loop
raise EOF(str(e) + '\n' + str(self))
EOF: End Of File (EOF) in read_nonblocking(). Empty string style platform.
The unpredictable failures make these tests noisy.
rdar://37046976
llvm-svn: 326739
This adds a wrapper around dotest, similar to llvm-lit in llvm. The
wrapper is created in the binary directory, next to LLDB and allows you
to invoke dotest without having to pass any of the configuration
arguments yourself. I think this could also be useful for re-running a
particular test case when it fails, as an alternative to "Command
Invoked".
The motivation for this is that I'd like to replace the driver part of
dotest with lit. As a first step, I'd like to have lit invoke dotest,
which would just run the complete test suite, completely identical to
what the CMake target does today. Once this is in place, we can have lit
run dotest for the different test directories, and ultimately once per
python file. Along the way we can strip out driver functionality from
dotest where appropriate.
https://reviews.llvm.org/D44002
llvm-svn: 326687
It turns out that setting the clang module cache after LLDB has a
Target can be too late. In particular, the Swift language plugin needs
to know the setting without having access to a Target. This patch
moves the setting into the *LLDB* module cache, where it is a global
setting that is available before any Target is created and more
importantly, is shared between all Targets.
rdar://problem/37944432
Differential Revision: https://reviews.llvm.org/D43984
llvm-svn: 326628
Adding categories to inline tests does not work because the attribute
is set at the function level. For methods, this means it applies to all
instances of that particular class. While this is what we want in most
cases, it's not for inline tests, where different instances correspond
to different tests.
With the workaround in place, assigning a category to one test resulted
in the category applied to *all* inline tests.
This patch removes the workaround and throws an exception with an
informative error message, to prevent this from happening in the future.
llvm-svn: 326552
Summary:
The inferior was sleeping before doing any interesting work. I remove that
to make the test faster.
While looking at the purpose of the test (to check that watchpoints are
propagated to all existing threads - r140757) I noticed that the test has
diverged from the original intention and now it creates the threads *after* the
watchpoint is set (this probably happened during the std::thread refactor).
After some discussion, we decided both scenarios make sense, so I modify the
test to test both.
The watchpoint propagation functionality is not really debug info depenent, so
I also stop replication of this test. This brings the test's time from ~108s
down to 4s.
Reviewers: davide, jingham
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43857
llvm-svn: 326514
gcc will say that the type of "this" is "T * const", clang "T *".
Compare the unqualified type names to erase the difference between the
two, as the constness is not a part of this test.
FWIW, I think that the gcc behavior makes more sense here.
llvm-svn: 326449
Before the change to compile tests out-of-tree, the cleanup classmethod
in TestQuoting.py would remove a temp file. After the change it threw an
exception due to a malformed call to getBuildArtifact().
Bring back the old behavior.
llvm-svn: 326414
Tim Shen