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'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
The lldb-server unit tests don't test the right thing when the debug
server in use is copied from somewhere else. This can lead to spurious
test failures.
Disable these unit tests when an external debug server is in use.
Fixes llvm.org/PR36494.
llvm-svn: 326001
Removing the template arguments and most of the mutating methods from
CleanUp makes it easier to understand and reuse.
In its present state, CleanUp would be too cumbersome to adapt to cases
where multiple objects need to be released. Take for example this change
in swift-lldb:
https://github.com/apple/swift-lldb/pull/334/files#diff-6f474df750f75c8ba675f2a8408a5629R219
This change is simple to express with the new CleanUp, but not so simple
with the old version.
Differential Revision: https://reviews.llvm.org/D43662
llvm-svn: 325964
Summary:
The issue was that we were parsing the registers into 64-bit integers
and the calling swapByteOrder without regard for the actual size of the
register. This switches the test to use the RegisterValue class which
tracks the register size, and knows how to initialize itself from a
piece of memory (so we don't need to swap byte order ourselves).
Reviewers: eugene, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D43376
llvm-svn: 325511
Summary:
Right now the test client is not parsing register values correctly,
which is manifesting itself in one test failing on 32-bit architectures
(pr36013). This parses the information from the qRegisterInfo packets
and stores it in the client, which will enable fixing the parsing in a
follow up commit.
I am also adding a new templated SendMessage overload, which enables one
to send a message get a parsed response in a single call.
Reviewers: eugene, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D43076
llvm-svn: 324722
Now incorrect type argument that looks like T<A><B> doesn't
cause an assert, but just a parsing error.
Bug: 36224
Differential Revision: https://reviews.llvm.org/D42939
llvm-svn: 324380
Davide pointed out this would be useful if the file ever needs to be
regenerated (and I certainly agree).
I also replace the test binary with a slightly smaller one -- I intended
to do this in the original commit, but I forgot to add it to the patch
as I was juggling several things at the same time.
llvm-svn: 324256
ObjectFileELF::GetModuleSpecifications contained a lot of tip-toing code
which was trying to avoid loading the full object file into memory. It
did this by trying to load data only up to the offset if was accessing.
However, in practice this was useless, as 99% of object files we
encounter have section headers at the end, so we would load the whole
file as soon as we start parsing the section headers.
In fact, this would break as soon as we encounter a file which does
*not* have section headers at the end (yaml2obj produces these), as the
access to .strtab (which we need to get the section names) was not
guarded by this offset check.
As this strategy was completely ineffective anyway, I do not attempt to
proliferate it further by guarding the .strtab accesses. Instead I just
lead the full file as soon as we are reasonably sure that we are indeed
processing an elf file.
If we really care about the load size here, we would need to reimplement
this to just load the bits of the object file we need, instead of
loading everything from the start of the object file to the given
offset. However, given that the OS will do this for us for free when
using mmap, I think think this is really necessary.
For testing this I check a (tiny) SO file instead of yaml2obj-ing it
because the fact that they come out first is an implementation detail of
yaml2obj that can change in the future.
llvm-svn: 324254
Summary:
The difference between this and regular LLDB_LOG is that this one clears
the error object unconditionally. This was inspired by the
ObjectFileELF bug (r322664), where the error object was being cleared
only if logging was enabled.
Reviewers: davide, zturner, jingham, clayborg
Subscribers: lldb-commits, emaste
Differential Revision: https://reviews.llvm.org/D42182
llvm-svn: 323753
Summary:
The ObjectFile class was used to determine the architecture of a running
process by inspecting it's main executable. There were two issues with
this:
- it's in the wrong layer
- the call can be very expensive (it can end up computing the crc of the
whole file).
Since the process is running on the host, ideally we would be able to
just query the data straight from the OS like darwin does, but there
doesn't seem to be a reasonable way to do that. So, this fixes the
layering issue by using the llvm object library to inspect the file.
Since we know the process is already running on the host, we just need
to peek at a few bytes of the elf header to determine whether it's 32-
or 64-bit (which should make this faster as well).
Pretty much the same logic was implemented in
NativeProcessProtocol::ResolveProcessArchitecture, so I delete this
logic and replace calls with GetProcessInfo.
Reviewers: eugene, krytarowski
Subscribers: mgorny, hintonda, lldb-commits
Differential Revision: https://reviews.llvm.org/D42488
llvm-svn: 323637
Summary: We can't use unique_ptr's here because we use those variables as `out` parameters to some functions. Discovered by the memory sanitizer.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D42386
llvm-svn: 323138
Summary: float can't represent the given value in the literal, so we get this UB error: `runtime error: 1.23457e+48 is outside the range of representable values of type 'float'`. The test seems to not rely on this specific value, so let's just choose a smaller one that can be represented.
Reviewers: uweigand
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D42338
llvm-svn: 323081
Summary: We never delete the created instances, so those test fail with the memory sanitizer.
Reviewers: jasonmolenda
Reviewed By: jasonmolenda
Subscribers: aemerson, javed.absar, kristof.beyls, lldb-commits
Differential Revision: https://reviews.llvm.org/D42336
llvm-svn: 323076
Summary:
- Fix a null array access bug. This happens when creating the lldb type for a function that has no argument.
- Implement SymbolFilePDB::ParseTypes method. Using `lldb-test symbols` will show all supported types in the target.
- Create lldb types for variadic function, PDBSymbolTypePointer, PDBSymbolTypeBuiltin
- The underlying builtin type for PDBSymbolTypeEnum is always `Int`, correct it with the very first enumerator's encoding if any. This is more accurate when the underlying type is not signed or another integer type.
- Fix a bug when the compiler type is not created based on PDB_BuiltinType. For example, basic type `long` is of same width as `int` in a 32-bit target, and the compiler type of former one will be represented by the one generated for latter if using the default method. Introduce a static function GetBuiltinTypeForPDBEncodingAndBitSize to correct this issue.
- Basic type `long double` and `double` have the same bit size in MSVC and there is no information in a PDB to distinguish them. The compiler type of the former one is represented by the latter's.
- There is no line informaton about typedef, enum etc in a PDB and the source and line information for them are not shown.
- There is no information about scoped enumeration. The compiler type is represented as an unscoped one.
Reviewers: zturner, lldb-commits, davide, asmith
Reviewed By: zturner, asmith
Subscribers: llvm-commits, davide
Differential Revision: https://reviews.llvm.org/D41427
llvm-svn: 322995
This removes boilerplate for setting up a log channel and capturing the
output from some of the tests. I do this by moving the setup code into a
test fixture and adding a logAndTakeOutput utility function to log some
string and then retrieve it from the log.
I also use some googlemock goodies to simplify a couple of assertions.
llvm-svn: 322653
Summary:
Gdb servers like openocd may send many $O reply packets for the client to output during a qRcmd command sequence. Currently, lldb interprets the first O packet as an unexpected response. Besides generating no output, this causes lldb to get out of sync with future commands because it continues reading O packets from the first command as response to subsequent commands.
This patch handles any O packets during an qRcmd, treating the first non-O packet as the true response.
Preliminary discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013078.html
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D41745
Patch by Owen Shaw <llvm@owenpshaw.net>
llvm-svn: 322190
Summary:
There was some confusion in the code about how to represent process
environment. Most of the code (ab)used the Args class for this purpose,
but some of it used a more basic StringList class instead. In either
case, the fact that the underlying abstraction did not provide primitive
operations for the typical environment operations meant that even a
simple operation like checking for an environment variable value was
several lines of code.
This patch adds a separate Environment class, which is essentialy a
llvm::StringMap<std::string> in disguise. To standard StringMap
functionality, it adds a couple of new functions, which are specific to
the environment use case:
- (most important) envp conversion for passing into execve() and likes.
Instead of trying to maintain a constantly up-to-date envp view, it
provides a function which creates a envp view on demand, with the
expectation that this will be called as the very last thing before
handing the value to the system function.
- insert(StringRef KeyEqValue) - splits KeyEqValue into (key, value)
pair and inserts it into the environment map.
- compose(value_type KeyValue) - takes a map entry and converts in back
into "KEY=VALUE" representation.
With this interface most of the environment-manipulating code becomes
one-liners. The only tricky part was maintaining compatibility in
SBLaunchInfo, which expects that the environment entries are accessible
by index and that the returned const char* is backed by the launch info
object (random access into maps is hard and the map stores the entry in
a deconstructed form, so we cannot just return a .c_str() value). To
solve this, I have the SBLaunchInfo convert the environment into the
"envp" form, and use it to answer the environment queries. Extra code is
added to make sure the envp version is always in sync.
(This also improves the layering situation as Args was in the Interpreter module
whereas Environment is in Utility.)
Reviewers: zturner, davide, jingham, clayborg
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D41359
llvm-svn: 322174
Summary: D41086 fixed an exception in FindTypes()/FindTypesByRegex() and caused two lldb unit test to fail. This change updates the unit tests to pass again.
Reviewers: zturner, lldb-commits, labath, clayborg, asmith
Reviewed By: asmith
Differential Revision: https://reviews.llvm.org/D41550
llvm-svn: 321511
Summary:
Make sure we propagate environment when starting debugserver with a pre-loaded
inferior. AFAIK, RNBRunLoopLaunchInferior is only called in pre-loaded inferior
scenario, so we can just pick up the debugserver environment instead of trying
to construct an envp from the (empty) context.
This makes debugserver pass an test added for an equivalent lldb-server fix.
Reviewers: jasonmolenda, clayborg
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D41352
llvm-svn: 321355
Summary:
It was possible when searching for a symbol by regex in a pdb that an invalid regex would cause an exception on Windows. This updates the code to avoid throwing an exception.
When fixing the exception it was decided there is no reason to search for a symbol in a pdb by regex. To support this, SymbolFilePDB::FindTypes() now only searches for types by name and no longer calls FindTypesByRegEx().
Reviewers: zturner, lldb-commits
Reviewed By: zturner
Subscribers: clayborg
Differential Revision: https://reviews.llvm.org/D41086
llvm-svn: 321344
The recent UUID cleanups exposed a bug in the parsing code for the
jModulesInfo response, which was passing wrong value for the second
argument to UUID::SetFromStringRef (it passed the length of the string,
whereas the correct value should be the number of decoded bytes we
expect to receive).
This was not picked up by tests, because they test with 16-byte uuids,
for which the function happens to do the right thing even if the length
does not match (if the length does not match, the function does not
update m_num_uuid_bytes member, but that member is already 16 to begin
with).
I fix that and add a test with 20-byte uuid to catch if this regresses.
I have also added more safeguards into the parsing code to fail if we
cannot parse the entire uuid field we recieve. While testing the latter
part, I noticed that the "negative" jModulesInfo tests were succeeding
because we were sending malformed json (and not because the json
contents was invalid), so I make those tests a bit more robuts as well.
llvm-svn: 320985
Summary:
We were failing to propagate the environment when lldb-server was
started with a pre-loaded process
(e.g.: lldb-server gdbserver -- inferior --inferior_args)
This patch makes sure the environment is propagated. Instead of adding a
new GDBRemoteCommunicationServerLLGS::SetLaunchEnvironment function to
complement SetLaunchArgs and SetLaunchFlags, I replace these with a
more generic SetLaunchInfo, which can be used to set any launch-related
property.
The accompanying test also verifies that the server correctly terminates
the connection after sending the exit packet (specifically, that it does
not send the exit packet twice).
Reviewers: clayborg, eugene
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D41070
llvm-svn: 320984
Summary:
lldb-server was sending the "exit" packet (W??) twice. This happened
because it was handling both the pre-exit (PTRACE_EVENT_EXIT) and
post-exit (WIFEXITED) as exit events. We had some code which was trying
to detect when we've already sent the exit packet, but this stopped
working quite a while ago.
This never really caused any problems in practice because the client
automatically closes the connection after receiving the first packet, so
the only effect of this was some warning messages about extra packets
from the lldb-server test suite, which were ignored because they didn't
fail the test.
The new test suite will be stricter about this, so I fix this issue
ignoring the first event. I think this is the correct behavior, as the
inferior is not really dead at that point, so it's premature to send the
exit packet.
There isn't an actual test yet which would verify the exit behavior, but
in my next patch I will add a test which will also test this
functionality.
Reviewers: eugene
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D41069
llvm-svn: 320961
Summary:
This makes StopReply class abstract, so that we can represent different
types of stop replies such as StopReplyStop and StopReplyExit (there
should also be a StopReplySignal, but I don't need that right now so I
haven't implemented it yet).
This prepares the ground for a new test I'm writing.
Reviewers: eugene, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D41067
llvm-svn: 320820
Summary:
We use the llvm decompressor to decompress SHF_COMPRESSED sections. This enables
us to read data from debug info sections, which are sometimes compressed,
particuarly in the split-dwarf case. This functionality is only available if
llvm is compiled with zlib support.
Reviewers: clayborg, zturner
Subscribers: emaste, mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D40616
llvm-svn: 320813
Summary:
Adding a new test would require one to duplicate a significant part of
the existing test that we have. This attempts to reduce that by moving
some part of that code to the test fixture. The StandardStartupTest
fixture automatically starts up the server and connects it to the
client. I also add a more low-level TestBase fixture, which allows one
to start up the client and server in a custom way (I am going to need
this for the test I am writing).
Reviewers: eugene, zturner
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D41066
llvm-svn: 320809
Host::GetEnvironment returns a StringList, but the interface for
launching a process takes Args. The fact that we use two classes for
representing an environment is not ideal, but for now we should at least
have an easy way to convert between the two.
llvm-svn: 320366
Summary:
For ptys (at least on Linux), the end-of-file (closing of the slave FD)
is signalled by the POLLHUP flag. We were ignoring this flag, which
meant that when this happened, we would spin in a loop, continuously
calling poll(2) and not making any progress.
This makes sure we treat POLLHUP as a read event (reading will return
0), and we call the registered callback when it happens. This is the
behavior our clients expect (and is consistent with how select(2)
works).
Reviewers: eugene, beanz
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D41008
llvm-svn: 320345
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
llvm-svn: 319840
1. Move TaskPool into the namespace lldb_private.
2. Add missing std::move in TaskPoolImpl::Worker.
3. std:🧵:hardware_concurrency may return 0,
handle this case correctly.
Differential revision: https://reviews.llvm.org/D40587
Test plan: make check-all
llvm-svn: 319492
Summary:
llvm::APSInt(0) asserts because it creates an int with bit-width 0 and
not (as I thought) a value 0.
Theoretically it should be sufficient to change this to APSInt(1), as
the intention there was that the value of the first argument should be
ignored if the type is invalid, but that would look dodgy.
Instead, I use llvm::Optional to denote an invalid value and use a
special struct instead of a std::pair, to reduce typing and increase
clarity.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D40615
llvm-svn: 319414
The rationale here is that ArchSpec is used throughout the codebase,
including in places which should not depend on the rest of the code in
the Core module.
This commit touches many files, but most of it is just renaming of
#include lines. In a couple of cases, I removed the #include ArchSpec
line altogether, as the file was not using it. In one or two places,
this necessitated adding other #includes like lldb-private-defines.h.
llvm-svn: 318048
Summary:
In D39387, I was quick to jump to conclusion that ArchSpec has no
external dependencies. It turns there still was one call to
HostInfo::GetArchitecture left -- for implementing the "systemArch32"
architecture and friends.
Since GetAugmentedArchSpec is the place we handle these "incomplete"
triples that don't specify os or vendor and "systemArch" looks very much
like an incomplete triple, I move its handling there.
After this ArchSpec *really* does not have external dependencies, and
I'll move it to the Utility module as a follow-up.
Reviewers: zturner, clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39896
llvm-svn: 318046
Summary:
Despite it's name, GetTemplateArgument was only really working for Type
template arguments. This adds the ability to retrieve integral arguments
as well (which I've needed for the std::bitset data formatter).
I've done this by splitting the function into three pieces. The idea is
that one first calls GetTemplateArgumentKind (first function) to
determine the what kind of a parameter this is. Based on that, one can
then use specialized functions to retrieve the correct value. Currently,
I only implement two of these: GetTypeTemplateArgument and
GetIntegralTemplateArgument.
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39844
llvm-svn: 318040
Summary:
These tests used to log the error message and return plain bool mainly
because at the time they we written, we did not have a nice way to
assert on llvm::Error values. That is no longer true, so replace this
pattern with a more idiomatic approach.
As a part of this patch, I also move the formatting of
GDBRemoteCommunication::PacketResult values out of the test code, as
that can be useful elsewhere.
Reviewers: zturner, eugene
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D39790
llvm-svn: 317795
Summary:
r316368 broke this build when it introduced a reference to a pthread
function to the Utility module. This caused cmake to generate an
incorrect link line (wrong order of libs) because it did not see the
dependency from Utility to the system libraries. Instead these libraries
were being manually added to each final target.
This changes moves the dependency management from the individual targets
to the lldbUtility module, which is consistent with how llvm does it.
The final targets will pick up these libraries as they will be a part of
the link interface of the module.
Technically, some of these dependencies could go into the host module,
as that's where most of the os-specific code is, but I did not try to
investigate which ones.
Reviewers: zturner, sylvestre.ledru
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D39246
llvm-svn: 316997
Summary:
ArchSpec::SetTriple was taking a Platform as an argument, and used it to
fill in missing pieces of the specified triple. I invert the dependency
by moving this code to other classes. For this purpose, I've created
three new functions.
- HostInfo::GetAugmentedArchSpec: fills in the triple using the host
platform (this used to be implemented by passing a null platform
pointer). By putting this code in the Host module, we can provide a
way to anyone who does not have a platform instance (lldb-server) an
easy way to get Host data.
- Platform::GetAugmentedArchSpec: if you have a platform instance, you
can call this to let it fill in the triple.
- static Platform::GetAugmentedArchSpec: implements the "if platform ==
0 then use_host() else use_platform()" part.
Reviewers: zturner, jingham, clayborg
Subscribers: mgorny, javed.absar, lldb-commits
Differential Revision: https://reviews.llvm.org/D39387
llvm-svn: 316987
Summary:
Without this, the launching of the test inferior may fail if it depends
on some component of the environment (most likely LD_LIBRARY_PATH). This
makes sure we propagate the environment variable to the inferior
process.
Reviewers: eugene
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39010
llvm-svn: 316244
Summary:
This adds support for running the lldb-server test suite (currently consisting
of only one test) against the debugserver. Currently, the choice which binary
to test is based on the host system. This will need to be replaced by something
more elaborate if/when lldb-server starts supporting debugging on darwin.
I need to make a couple of tweaks to the test client to work with debugserver:
- debugserver has different command-line arguments - launching code adjusted to
handle that
- debugserver sends duplicate "medata" fields in the stop reply packet -
adjusted stop-reply parsing code to handle that
- debugserver replies to the k packet instead of just dropping the connection -
stopping code adjusted, although we should probably consider aligning the
behavior of the two stubs in this case
Reviewers: jmajors, beanz
Subscribers: srhines, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D35311
llvm-svn: 316010
* Prevent dumping of characters in DumpDataExtractor() with
item_byte_size bigger than 8 bytes. This case is not supported by the
code and results in a crash because the code calls
DataExtractor::GetMaxU64Bitfield() -> GetMaxU64() that asserts for
byte size > 8 bytes.
* Teach DataExtractor::GetMaxU64(), GetMaxU32(), GetMaxS64() and
GetMaxU64_unchecked() how to handle byte sizes that are not a multiple
of 2. This allows DumpDataExtractor() to dump characters and booleans
with item_byte_size in the interval of [1, 8] bytes. Values that are
not a multiple of 2 would previously result in a crash because they
were not handled by GetMaxU64().
llvm-svn: 315444
Summary:
At present, several gtests in the lldb open source codebase are using
#include statements rooted at $(SOURCE_ROOT)/${LLDB_PROJECT_ROOT}.
This patch cleans up this directory/include structure for both CMake and
Xcode build systems.
rdar://problem/33835795
Reviewers: zturner, jingham, beanz
Reviewed By: beanz
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D36598
llvm-svn: 314849
Summary:
This allows for the stack size to be configured, which isn't
possible with std::thread. Prevents overflowing the stack when
performing complex operations in the task pool on darwin,
where the default pthread stack size is only 512kb.
This also moves TaskPool from Utility to Host.
Reviewers: labath, tberghammer, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D37930
llvm-svn: 313637
Turns out WITH_LOCKDOWN define changes the struct layout and constructor implementation for RNBSocket which is used in debugserver.cpp, so we need to make sure this is consistent.
In the future we should change WITH_LOCKDOWN to be configured in a generated header, but for now we can just set it correctly.
<rdar://problem/33900552>
llvm-svn: 312666
The socket bind address should either be localhost or anyaddress. This bug in the listen behavior was preventing lldb-server from opening sockets for non-localhost connections.
The added test verifies that opening an anyaddress socket works and has a non-zero port assignment.
This should resolve PR34183.
llvm-svn: 312008
The Process/gdb-remote test now requires the LLVMTestingSupport library
that is not installed by LLVM. As a result, when doing an out-of-source
build it fails being unable to find the library. To solve that, build
a local copy of the library when building LLDB with unittests and LLVM
sources available. This is based on how we deal with bundled gtest
sources.
Differential Revision: https://reviews.llvm.org/D36886
llvm-svn: 311355
Summary:
The EncodingError test ensures that trying to encode a multibyte wchar
with a given codepage fails. If setlocale() fails, the encoding is
performed using the current locale, which may or may not fail.
This patch asserts that both setlocale() operations are successful, as
well as falling back to a widely available unibyte encoding for
non-Windows systems.
<rdar://problem/33782806>
Reviewers: zturner, labath, lhames
Reviewed By: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D36496
llvm-svn: 310499
While adding IPv6 support to debugserver I broke handling wildcard addresses and fully qualified address filtering. This patch resolves that bug and adds a test for matching the address "*".
<rdar://problem/32947613>
llvm-svn: 307957
blocks of memory, and if the final bytes of that block look like a long
x86 instruction, it can cause the llvm disassembler to read past the end
of the buffer. Use the maximum allowed instruction length that we pass
to the llvm disassembler as a way to limit this to the size of the buffer.
An example of how to trigger this is when lldb does a function call, it
puts a breakpoint on the beginning of main() and uses that as the return
address from the function call. When we stop at that location, lldb may
try to find the first frame up the stack. Because this is on the first
instruction of a function, it will get the word-size value at the stack
pointer and assume that this was the caller's pc value. But this is random
stack memory and could point to anything - an object in memory, something
in the data section, whatever. And if we have a symbol for that thing,
we'll try to disassemble it.
This was leading to infrequent crashes in customer scenarios; figured out
what was happening with address sanitizer.
<rdar://problem/30463256>
llvm-svn: 307454
Summary:
The classes have no dependencies, and they are used both by lldb and
lldb-server, so it makes sense for them to live in the lowest layers.
Reviewers: zturner, jingham
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34746
llvm-svn: 306682
Summary:
Fetching an input file required about five lines of code, and this was
repeated in multiple unit tests, with slight variations. Add a helper
function for doing that into the lldbUtilityMocks module (which I rename
to lldbUtilityHelpers to commemorate the fact it includes more than
mocks)
Reviewers: zturner, eugene
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34683
llvm-svn: 306668
Summary:
The instruction pattern:
and $-16, %esp
sub $imm, %esp
...
lea imm(%ebp), %esp
appears when the compiler is realigning the stack (for example in
main(), or almost everywhere with -mstackrealign switch). The "and"
instruction is very difficult to model, but that's not necessary, as
these frames are always %ebp-based (the compiler also needs a way to
restore the original %esp). Therefore the plans we were generating for
these function were almost correct already. The only place we were doing
it wrong were the last instructions of the epilogue (usually just
"ret"), where we had to revert to %esp-based unwinding, as the %ebp had
been popped already.
This was wrong because our "distance of esp from cfa" counter had picked
up the "sub" instruction (and incremented the counter) but it had not
seen that the register was reset by the "lea" instruction.
This patch fixes that shortcoming, and adds a test for handling
functions like this.
I have not been able to tickle the compiler into producing a 64-bit
function with this pattern, but I don't see a reason why it couldn't
produce it, if it chose to, so I add a x86_64 test as well.
Reviewers: jasonmolenda, tberghammer
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D34750
llvm-svn: 306666
Summary:
instead of using a boolean to differentiate between the two section
types, use an enum to make the intent clearer.
I also remove the RegisterKind argument from the constructor, as this
can be deduced from the Type argument.
Reviewers: clayborg, jasonmolenda
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D34681
llvm-svn: 306521
Summary:
This patch implements support for Intel(R) Processor Trace
in lldb server. The changes have support for
starting/stopping and reading the trace data. The code
is only available on Linux versions where the perf
attributes for aux buffers are available.
The patch also consists of Unit tests for testing the
core buffer reading function.
Reviewers: lldb-commits, labath, clayborg, zturner, tberghammer
Reviewed By: labath, clayborg
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D33674
llvm-svn: 306516
Summary:
This is a beefed-up version of D33504, which adds support for dwarf 4
debug_frame section format.
The main difference here is that the decision whether to use eh_frame or
debug_frame is done on a per-function basis instead of per-object file.
This is necessary because one module can contain both sections (for
example, the start files added by the linker will typically pull in
eh_frame), but we want to be able to access both, for maximum
information.
I also add unit test for parsing various CFI formats (eh_frame,
debug_frame v3 and debug_frame v4).
Reviewers: jasonmolenda, clayborg
Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha
Differential Revision: https://reviews.llvm.org/D34613
llvm-svn: 306397
Summary:
It had a dependency on StringConvert and file reading code, which is not
in Utility. I've replaced that code by equivalent llvm operations.
I've added a unit test to demonstrate that parsing a file still works.
Reviewers: zturner, jingham
Subscribers: kubamracek, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34625
llvm-svn: 306394
Instead of every test creating a client-server combo, do that in the
SetUp method of the test fixture. This also means that we can rely on
gtest to not run the test if the SetUp method fails and delete the
if(HasFailure) calls.
llvm-svn: 306013
Summary:
A number of places were trying to decode the result of wait(). Add a simple
utility function that does that and a struct that encapsulates the
decoded result. Then also provide a pretty-printer for that class.
Reviewers: zturner, krytarowski, eugene
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33998
llvm-svn: 305689
Summary:
ProcessLauncherPosix was using posix_spawn for launching the process,
but this function is not available on all platforms we support, and even
where it was avaialable, it did not support the full range of options we
require for launching (most importantly, launching in stop-on-entry
mode). For these reasons, the set of ifdefs around these functions has
grown untractably large, and we were forced to implement our own
launcher from more basic primitives anyway (ProcessLauncherPosixFork --
used on Linux, Android, and NetBSD).
Therefore, I remove this class, and move the relevant parts of the code
to the darwin-specific Host.mm file. This is the platform that code was
originally written for anyway, and it's the only platform where this
implementation makes sense (e.g. the lack of the "thread-specific
working directory" concept makes these functions racy on all other
platforms). This allows us to remove a lot of ifdefs and simplify the
code.
Effectively, the only change this introduces is that FreeBSD will now
use the fork-based launcher instead of posix_spawnp. That sholdn't be a
problem as this approach works at least on one other BSD-based system
already.
Reviewers: krytarowski, emaste, jingham
Subscribers: srhines, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34236
llvm-svn: 305686
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.
Differential Revision: https://reviews.llvm.org/D33843
llvm-svn: 304864
Summary:
This is a new C++ test framework based on Google Test, and one working
example test.
The intention is to replace the existing tests in
packages/Python/lldbsuite/test/tools/lldb-server/ with this suite
and use this framework for all new client server tests.
Reviewers: labath, beanz
Reviewed By: labath, beanz
Subscribers: beanz, emaste, zturner, tberghammer, takuto.ikuta, krytarowski, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D32930
Patch by Jason Majors <jmajors@google.com>
llvm-svn: 304793
Summary:
- Added API to access data types
-- integer, double, array, string, boolean and dictionary data types
-- Earlier user had to parse through the string output to get these
values
- Added Test cases for API testing
- Added new StructuredDataType enum in public include file
-- Replaced locally-defined enum in StructuredData.h with this new
one
-- Modified other internal files using this locally-defined enum
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: clayborg, lldb-commits
Reviewed By: clayborg
Subscribers: labath
Differential Revision: https://reviews.llvm.org/D33434
llvm-svn: 304138
Summary:
The changes consist of new packets for trace manipulation and
trace collection. The new packets are also documented. The packets
are capable of providing custom trace specific parameters to start
tracing and also retrieve such configuration from the server.
Reviewers: clayborg, lldb-commits, tberghammer, labath, zturner
Reviewed By: clayborg, labath
Subscribers: krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D32585
llvm-svn: 303972
Summary:
This adds functions to convert between llvm::Error and Status classes.
Posix errors in Status are represented as llvm::ECError, and the rest as
llvm::StringError.
For the conversion from Error to Status, ECError is again represented as
a posix error in Status, while other errors are stored as generic errors
and only the string value is preserved.
Reviewers: zturner, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D33241
llvm-svn: 303348
The Timer destructor would grab a global mutex in order to update
execution time. Add a class to define a category once, statically; the
class adds itself to an atomic singly linked list, and thus subsequent
updates only need to use an atomic rather than grab a lock and perform a
hashtable lookup.
Differential Revision: https://reviews.llvm.org/D32823
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 303058
This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.
llvm-svn: 302872
Summary:
Many parallel tasks just want to iterate over all the possible numbers from 0 to N-1. Rather than enqueue N work items, instead just "map" the function across the requested integer space.
Reviewers: clayborg, labath, tberghammer, zturner
Reviewed By: clayborg, zturner
Subscribers: zturner, lldb-commits
Differential Revision: https://reviews.llvm.org/D32757
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 302223
Summary:
This adds a couple of unit tests to the MainLoop class. To get the
kqueue based version of the signal handling passing, I needed to
modify the implementation a bit to make the queue object persistent.
Otherwise, only the signals which are send during the Run call would get
processed, which did not match the ppoll behaviour.
I also took the opportunity to remove the ForEach template functions and
replace them with something more reasonable.
Reviewers: beanz, eugene
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D32753
llvm-svn: 302133
Summary:
If we have symbol information in a separate file, we need to be very
careful about presenting a unified section view of module to the rest of
the debugger. ObjectFileELF had code to handle that, but it was being
overly cautious -- the section->GetFileSize()!=0 meant that the
unification would fail for sections which do not occupy any space in the
object file (e.g., .bss). In my case, that manifested itself as not
being able to display the values of .bss variables properly as the
section associated with the variable did not have it's load address set
(because it was not present in the unified section list).
I test this by making sure the unified section list and the variables
refer to the same section.
Reviewers: eugene, zturner
Subscribers: tberghammer, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D32434
llvm-svn: 301917
This support was landed in r300579, and reverted in r300669 due to failures on the bots.
The failures were caused by sockets not being properly closed, and this updated version of the patches should resolve that.
Summary from the original change:
This patch adds IPv6 support to LLDB/Host's TCP socket implementation. Supporting IPv6 involved a few significant changes to the implementation of the socket layers, and I have performed some significant code cleanup along the way.
This patch changes the Socket constructors for all types of sockets to not create sockets until first use. This is required for IPv6 support because the socket type will vary based on the address you are connecting to. This also has the benefit of removing code that could have errors from the Socket subclass constructors (which seems like a win to me).
The patch also slightly changes the API and behaviors of the Listen/Accept pattern. Previously both Listen and Accept calls took an address specified as a string. Now only listen does. This change was made because the Listen call can result in opening more than one socket. In order to support listening for both IPv4 and IPv6 connections we need to open one AF_INET socket and one AF_INET6 socket. During the listen call we construct a map of file descriptors to addrin structures which represent the allowable incoming connection address. This map removes the need for taking an address into the Accept call.
This does have a change in functionality. Previously you could Listen for connections based on one address, and Accept connections from a different address. This is no longer supported. I could not find anywhere in LLDB where we actually used the APIs in that way. The new API does still support AnyAddr for allowing incoming connections from any address.
The Listen implementation is implemented using kqueue on FreeBSD and Darwin, WSAPoll on Windows and poll(2) everywhere else.
https://reviews.llvm.org/D31823
llvm-svn: 301492
Summary:
the reason for this is two-fold:
- getaddrinfo without the extra arguments will return the same
(network-level) address multiple times, once for each supported
transport protocol, which is not what is usually intended (it certainly
wasn't in D31823)
- it enables us to rewrite the getaddrinfo member function in terms of
the static GetAddressInfo function.
Reviewers: beanz, tberghammer
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32357
llvm-svn: 301168
Summary:
MergeFrom was updating the architecture if the target triple did not
have it set. However, it was leaving the core field as invalid. This
resulted in assertion failures in core file tests as a missing core
meant we were unable to compute the address byte size properly.
Add a unit test for the new behaviour.
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32221
llvm-svn: 300836
The break the linux bots (and probably any other machine which would
run the test suite in a massively parallel way). The problem is that it
can happen that we only successfully create an IPv6 listening socket
(because the relevant IPv4 port is used by another process) and then the
connecting side attempts to connect to the IPv4 port and fails.
It's not very obvious how to fix this problem, so I am reverting this
until we come up with a solution.
llvm-svn: 300669
Summary: This patch adds IPv6 support to debugserver. It follows a similar pattern to the changes proposed for LLDB/Host except that the listen implementation is only with kqueue(2) because debugserver is only supported on Darwin.
Reviewers: jingham, jasonmolenda, clayborg
Reviewed By: clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D31824
llvm-svn: 300580
Summary:
This patch adds IPv6 support to LLDB/Host's TCP socket implementation. Supporting IPv6 involved a few significant changes to the implementation of the socket layers, and I have performed some significant code cleanup along the way.
This patch changes the Socket constructors for all types of sockets to not create sockets until first use. This is required for IPv6 support because the socket type will vary based on the address you are connecting to. This also has the benefit of removing code that could have errors from the Socket subclass constructors (which seems like a win to me).
The patch also slightly changes the API and behaviors of the Listen/Accept pattern. Previously both Listen and Accept calls took an address specified as a string. Now only listen does. This change was made because the Listen call can result in opening more than one socket. In order to support listening for both IPv4 and IPv6 connections we need to open one AF_INET socket and one AF_INET6 socket. During the listen call we construct a map of file descriptors to addrin structures which represent the allowable incoming connection address. This map removes the need for taking an address into the Accept call.
This does have a change in functionality. Previously you could Listen for connections based on one address, and Accept connections from a different address. This is no longer supported. I could not find anywhere in LLDB where we actually used the APIs in that way. The new API does still support AnyAddr for allowing incoming connections from any address.
The Listen implementation is implemented using kqueue on FreeBSD and Darwin, WSAPoll on Windows and poll(2) everywhere else.
Reviewers: zturner, clayborg
Subscribers: jasonmolenda, labath, lldb-commits, emaste
Differential Revision: https://reviews.llvm.org/D31823
llvm-svn: 300579
Summary:
This patch refactors the CMake build system's support for building debugserver to allow us to build the majority of debugserver's sources into the debugserverCommon library which can then be reused by unit tests.
The first unit test I've written tests debug server's ability to accept incoming connections from LLDB. The test forks the process, and one side creates a listening socket using debugserver's socket API, the other side creates a transmitting socket using LLDB's TCPSocket class.
I have no clue where to even start getting this connected into the LLDB Xcode project, so for now these tests are CMake-only.
Reviewers: zturner, labath, jasonmolenda
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D31357
llvm-svn: 300111
Current implementation of CPlusPlusLanguage::MethodName::Parse() doesn't
get anywhere close to covering full extent of possible function declarations.
It causes incorrect behavior in avoid-stepping and sometimes messes
printing of thread backtrace.
This change implements more methodical parsing logic based on clang
lexer and simple recursive parser.
Examples:
void std::vector<Class, std::allocator<Class>>::_M_emplace_back_aux<Class const&>(Class const&)
void (*&std::_Any_data::_M_access<void (*)()>())()
Previous version of this change (D31451) was rolled back due to an issue
with Objective-C selectors being incorrectly recognized as a C++ identifier.
Differential Revision: https://reviews.llvm.org/D31451
llvm-svn: 299721
This caused a failure in the test case:
functionalities/breakpoint/objc/TestObjCBreakpoints.py
When we are parsing up names we stick interesting parts of the names
in various buckets, one of which is the ObjC selector bucket. The new
C++ name parser must be interfering with this process somehow.
<rdar://problem/31439305>
llvm-svn: 299489
Current implementation of CPlusPlusLanguage::MethodName::Parse() doesn't
get anywhere close to covering full extent of possible function declarations.
It causes incorrect behavior in avoid-stepping and sometimes messes
printing of thread backtrace.
This change implements more methodical parsing logic based on clang
lexer and simple recursive parser.
Examples:
void std::vector<Class, std::allocator<Class>>::_M_emplace_back_aux<Class const&>(Class const&)
void (*&std::_Any_data::_M_access<void (*)()>())()
Differential Revision: https://reviews.llvm.org/D31451
llvm-svn: 299374
Summary:
This aims to verify the validity of the response from the debugging
server in GDBRemoteCommunicationClient::GetMemoryRegionInfo. I was
working with ds2 (https://github.com/facebook/ds2) and encountered a bug
that caused the server's response to have a 'size' value of 0, which
caused lldb to behave incorrectly.
Reviewers: k8stone, labath, clayborg
Reviewed By: labath, clayborg
Subscribers: clayborg, sas, lldb-commits
Differential Revision: https://reviews.llvm.org/D31485
Change by Alex Langford <apl@fb.com>
llvm-svn: 299239
GetNormalizedPath seems to be slow, so it's worth
shortcutting it if possible. This change does so
when the filenames and not equal and we can tell
GetNormalizedPath would not make them equal.
Also added a test for "." final component since that
was missing.
llvm-svn: 298876
This was causing a test failure in one of LLDB's tests which
specifically dealt with a limitation in LLVM's implementation
of home_directory() that LLDB's own implementation had worked
around.
This limitation has been addressed in r298513 on the LLVM side,
so the failing test (which is now unnecessary as the limitation
no longer exists) was removed in r298519, allowing this patch to
be re-submitted without modification.
llvm-svn: 298526
Summary:
ProcFileReader is the cause of the dependency from Host to ProcessLinux
module. Since it's interface is also obsolete (ReadIntoDataBuffer is
trivially replaceable by llvm::MemoryBuffer functions and
ProcessLineByLine is trivially implementable with StringRefs), instead
of moving it around I'm planning to obliterate it. This is the first
step, where I remove a couple of occurences in linux/Host.cpp, and
modernize some code around that.
I have introduced linux/Support.h, which holds two utility functions
now, whose resposibility is to construct the appropriate proc file names
-- the only useful feature of ProcFileReader.
I add a couple of tests for these functions, and for
Host::GetProcessInfo. It's worth noting that these are the first
host-specific unit tests in lldb.
Reviewers: zturner, eugene
Subscribers: srhines, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D30942
llvm-svn: 297843
Summary:
previously we switched to llvm streams for log output, this completes
the switch for the error streams.
I also clean up the includes and remove the unused argument from
DisableAllLogChannels().
This required adding a bit of boiler plate to convert the output in the
command interpreter, but that should go away when we switch command
results to use llvm streams as well.
Reviewers: zturner, eugene
Subscribers: lldb-commits, emaste
Differential Revision: https://reviews.llvm.org/D30894
llvm-svn: 297812
One of the file name templates was occasionally generating the name
"fooa***", which conflicted with the one of the tests expectation that
there is only one item beginning with "fooa".
There doesn't seem to be a good reason for using random file templates
here, so just switch to a fixed set of files to increase
reproducibility.
llvm-svn: 297743
This reverts commit a6a29374662716710f80c8ece96629751697841e.
It has a few compilation failures that I don't have time to fix
at the moment.
llvm-svn: 297589
There were a couple of problems with this function on Windows. Different
separators and differences in how tilde expressions are resolved for
starters, but in addition there was no clear indication of what the
function's inputs or outputs were supposed to be, and there were no tests
to demonstrate its use.
To more easily paper over the differences between Windows paths,
non-Windows paths, and tilde expressions, I've ported this function to use
LLVM-based directory iteration (in fact, I would like to eliminate all of
LLDB's directory iteration code entirely since LLVM's is cleaner / more
efficient (i.e. it invokes fewer stat calls)). and llvm's portable path
manipulation library.
Since file and directory completion assumes you are referring to files and
directories on your local machine, it's safe to assume the path syntax
properties of the host in doing so, so LLVM's APIs are perfect for this.
I've also added a fairly robust set of unit tests. Since you can't really
predict what users will be on your machine, or what their home directories
will be, I added an interface called TildeExpressionResolver, and in the
unit test I've mocked up a fake implementation that acts like a unix
password database. This allows us to configure some fake users and home
directories in the test, so we can exercise all of those hard-to-test
codepaths that normally otherwise depend on the host.
Differential Revision: https://reviews.llvm.org/D30789
llvm-svn: 297585
Summary:
This fixes two threading issues in the logging code. The access to the
mask and options flags had data races when we were trying to
enable/disable logging while another thread was writing to the log.
Since we can log from almost any context, and we want it to be fast, so
I avoided locking primitives and used atomic variables instead. I have
also removed the (unused) setters for the mask and flags to make sure
that the only way to set them is through the enable/disable channel
functions.
I also add tests, which when run under tsan, verify that the use cases
like "doing an LLDB_LOGV while another thread disables logging" are
data-race-free.
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30702
llvm-svn: 297368
If QPassSignals packaet is supported by lldb-server, lldb-client will
utilize it and ask the server to ignore signals that don't require stops
or notifications.
Such signals will be immediately re-injected into inferior to continue
normal execution.
Differential Revision: https://reviews.llvm.org/D30520
llvm-svn: 297231
This functionality is subsumed by DataBufferLLVM, which is
also more efficient since it will try to mmap. However, we
don't yet support mmaping writable private sections, and in
some cases we were using ReadFileContents and then modifying
the buffer. To address that I've added a flag to the
DataBufferLLVM methods that allow you to map privately, which
disables the mmaping path entirely. Eventually we should teach
DataBufferLLVM to use mmap with writable private, but that is
orthogonal to this effort.
Differential Revision: https://reviews.llvm.org/D30622
llvm-svn: 297095
it was accessing the details of the Log class directly. Let it go
through the channel class instead.
This also discovered a bug when we were setting but not clearing the log
options when enabling a channel.
llvm-svn: 297053
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
Prior to MSVC 2015 we had to manually include this header any
time we were going to include <thread> or <future> due to a
bug in MSVC's STL implementation. This has been fixed in MSVC
for some time now, and we require VS 2015 minimum, so we can
remove this across all subprojects.
llvm-svn: 296906
Summary:
Use StringRef and ArrayRef where possible. This adds an accessor to the
Args class to get a view of the arguments as ArrayRef<const char *>.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30402
llvm-svn: 296592
load_size should be 64-bit unconditionally to match the underlying API.
This makes sure the MAX value correctly signals to auto-detect the file
size when mmap()ing.
llvm-svn: 296334
The channel refactor introduced a regression where we were not honoring
the log options passed when enabling the channel. Fix that and add a
test.
llvm-svn: 296329
After a series of patches on the LLVM side to get the mmaping
code up to compatibility with LLDB's needs, it is now ready
to go, which means LLDB's custom mmapping code is redundant.
So this patch deletes it all and uses LLVM's code instead.
In the future, we could take this one step further and delete
even the lldb DataBuffer base class and rely entirely on
LLVM's facilities, but this is a job for another day.
Differential Revision: https://reviews.llvm.org/D30054
llvm-svn: 296159
Summary:
The code was attempting to copy the shared pointer member in order to
guarantee atomicity, but this is not enough. Instead, protect the
pointer with a proper read-write mutex.
This bug was present here for a long time, but my recent refactors must
have altered the timings slightly, such that now this fails fairly often
when running the tests: the test runner runs the "log disable" command
just as the thread monitoring the lldb-server child is about to report
that the server has exited.
I add a test case for this. It's not possible to reproduce the race
deterministically in normal circumstances, but I have verified that
before the fix, the test failed when run under tsan, and was running
fine afterwards.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30168
llvm-svn: 295712
Summary:
I originally set out to move the NameMatches closer to the relevant
function and add some unit tests. However, in the process I've found a
couple of bugs in the implementation:
- the early exits where not always correct:
- (test==pattern) does not mean the match will always suceed because
of regular expressions
- pattern.empty() does not mean the match will fail because the "" is
a valid prefix of any string
So I cleaned up those and added some tests. The only tricky part here
was that regcomp() implementation on darwin did not recognise the empty
string as a regular expression and returned an REG_EMPTY error instead.
The simples fix here seemed to be to replace the empty expression with
an equivalent non-empty one.
Reviewers: clayborg, zturner
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D30094
llvm-svn: 295651
The way of injecting an error into the printf call was not working on
darwin - the C library still happily format the character. It only
returns an error after we use a wide character that does not fit into a
single byte, so switch the test to use that.
llvm-svn: 295443
Changes wrt. previous version:
- add #include <atomic>: fix build on windows
- add extra {} around the string literals used to initialize
llvm::StringLiteral: fix gcc build
llvm-svn: 295442
Summary:
We currently have two log channel registration mechanisms. One uses a
set of function pointers and the other one is based on the
PluginManager.
The PluginManager dependency is unfortunate, as logging
is also used in lldb-server, and the PluginManager pulls in a lot of
classes which are not used in lldb-server.
Both approach have the problem that they leave too much to do for the
user, and so the individual log channels end up reimplementing command
line argument parsing, category listing, etc.
Here, I replace the PluginManager-based approach with a one. The new API
is more declarative, so the user only needs to specify the list of list
of channels, their descriptions, etc., and all the common tasks like
enabling/disabling categories are hadled by common code. I migrate the
LogChannelDWARF (only user of the PluginManager method) to the new API.
In the follow-up commits I'll replace the other channels with something
similar.
Reviewers: clayborg, zturner, beanz
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D29895
llvm-svn: 295190
With this patch, the only dependency left is from Utility
to Host. After this is broken, Utility will finally be
standalone.
Differential Revision: https://reviews.llvm.org/D29909
llvm-svn: 295088
and use it in the appropriate log statements.
Formatting of chrono types in log messages was very clunky. This should
make it much nicer to use and give better output. For details of the
formatting options see the chrono formatter in llvm.
llvm-svn: 294738
Summary:
This converts LLDB's logging to use llvm streams instead of
lldb_private::Stream and friends. The changes are mostly
straight-forward and amount to s/lldb_private::Stream/llvm::raw_ostream.
The part worth calling out is the rewrite of the StreamCallback class.
Previously this class contained a per-thread buffer of data written. I
assume this had something to do with it trying to make sure each log
line is delivered as a single event, instead of multiple (possibly
interleaved) events. However, this is no longer relevant as the Log
class already writes things to a temporary buffer and then delivers the
message as a single "write", so I have just removed the code in
question.
Reviewers: zturner, clayborg
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D29615
llvm-svn: 294736
Summary:
This patch removes the over-specified dependencies from LLDBDependencies and instead relies on the dependencies as expressed in each library and tool.
This also removes the library looping in favor of allowing CMake to do its thing. I've tested this patch on Darwin, and found no issues, but since linker semantics vary by system I'll also work on testing it on other platforms too.
Help testing would be greatly appreciated.
Reviewers: labath, zturner
Subscribers: danalbert, srhines, mgorny, jgosnell, lldb-commits
Differential Revision: https://reviews.llvm.org/D29352
llvm-svn: 294515
Summary:
Per discussion in D28616, having two ways two request logging (log
enable lldb XXX verbose && log enable -v lldb XXX) is confusing. This
removes the first option and standardizes all code to use the second
one.
I've added a LLDB_LOGV macro as a shorthand for if(log &&
log->GetVerbose()) and switched most of the affected log statements to
use that (I've only left a couple of cases that were doing complex
computations in an if(log) block).
Reviewers: jingham, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D29510
llvm-svn: 294113
This moves the following classes from Core -> Utility.
ConstString
Error
RegularExpression
Stream
StreamString
The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
We started passing the list of libraries to link to the
add_lldb_unittest macro, but that macro wasn't actually doing anything
with them. Fix that.
llvm-svn: 293913
Summary:
Problem:
There are three filelds in the ELF header - e_phnum, e_shnum, and e_shstrndx -
that could be bigger than 64K and therefore do not fit in 16 bits reserved for
them in the header. If this happens, pretty often there is a special section at
index 0 which contains their real values for these fields in the section header
in the fields sh_info, sh_size, and sh_link respectively.
Fix:
- Rename original fields in the header declaration. We want to have them around
just in case.
- Reintroduce these fields as 32-bit members at the end of the header. By default
they are initialized from the header in Parse() method.
- In Parse(), detect the situation when the header might have been extended into
section info #0 and try to read it from the same data source.
- ObjectFileELF::GetModuleSpecifications accesses some of these fields but the
original parse uses too small data source. Re-parse the header if necessary
using bigger data source.
- ProcessElfCore::CreateInstance uses header with potentially sentinel values,
but it does not access these fields, so a comment here is enough.
Reviewers: labath
Reviewed By: labath
Subscribers: davidb, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D29095
Author: Eugene Birukov <eugenebi@hotmail.com>
llvm-svn: 293714
This adds the LLDB_LOG macro, which enables one to write more succinct log
statements.
if (log)
log->Printf("log something: %d", var);
becomes
LLDB_LOG(log, "log something: {0}, var);
The macro still internally does the "if(log)" dance, so the arguments are only
evaluated if logging is enabled, meaning it has the same overhead as the
previous syntax.
Additionally, the log statements will be automatically prefixed with the file
and function generating the log (if the corresponding new argument to the "log
enable" command is enabled), so one does not need to manually specify this in
the log statement.
It also uses the new llvm formatv syntax, which means we don't have to worry
about PRIx64 macros and similar, and we can log complex object (llvm::StringRef,
lldb_private::Error, ...) more easily.
Differential Revision: https://reviews.llvm.org/D27459
llvm-svn: 292360
Summary:
PrependPathComponent was unconditionally inserting path separators between the
path components. This is not correct if the prepended path is "/", which caused
problems down the line. Fix the function to use the same algorithm as
AppendPathComponent and add a test. This fixes one part of llvm.org/pr31611.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D28677
llvm-svn: 292100
Summary:
The formatter supports the same options as the string-like classes, i.e. the
ability to truncate the displayed string. I don't anticipate it would be much
used, but it seems consistent.
Reviewers: zturner, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D28519
llvm-svn: 291759
Previously it failed to handle nested types inside templated classes
making it impossible to look up these types using the fully qualified
name.
Differential revision: https://reviews.llvm.org/D28466
llvm-svn: 291559
Split the PDB tests into DWARF test and actual PDB tests, the latter
requiring DIA SDK. Use the new LLVMConfig.cmake LLVM_ENABLE_DIA_SDK
symbol to enable the PDB tests rather than relying on
llvm/Config/config.h private include file that is not available when
building standalone.
Differential Revision: https://reviews.llvm.org/D26249
llvm-svn: 290819
This adds formatv-backed formatting functions in various
places in LLDB such as StreamString, logging, constructing
error messages, etc. A couple of callsites are changed
from Printf style syntax to formatv style syntax to
illustrate its usage. Additionally, a FileSpec formatter
is introduced so that FileSpecs can be formatted natively.
Differential Revision: https://reviews.llvm.org/D27632
llvm-svn: 289922
LLVM build trees export the gtest library through a special export set. If you're building against a build tree you shouldn't need to re-add gtest, but if you're building against an installed LLVM you do.
llvm-svn: 288691
The core of the function was actually handling them correctly. However, the
early exit was being too optimistic and did not give the function a chance to
fire if the path did not contain dots as well.
Fix that and add a couple of unit tests.
llvm-svn: 288247
Summary:
Communication classes use the Timeout<> class to specify the timeout. Listener
class was converted to chrono some time ago, but it used a different meaning for
a timeout of zero (Listener: infinite wait, Communication: no wait). Instead,
Listener provided separate functions which performed a non-blocking event read.
This converts the Listener class to the new Timeout class, to improve
consistency. It also allows us to get merge the different GetNextEvent*** and
WaitForEvent*** functions into one. No functional change intended.
Reviewers: jingham, clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D27136
llvm-svn: 288238
This replaces the raw integer timeout parameters in the class with their
chrono-based equivalents. To achieve this, I have moved the Timeout class to a
more generic place and added a quick unit test for it.
llvm-svn: 287920
the chrono library there uses long long as the underlying chrono type, but
defines int64_t as long (or the other way around, I am not sure). In any case,
this caused the implicit conversion to not trigger. This should address that.
Also fix up the relevant unit test.
llvm-svn: 287867
This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and instead provide one function which returns a StringRef.
Direct access to the underlying buffer violates the concept of
a "stream" which is intended to provide forward only access,
and makes porting to llvm::raw_ostream more difficult in the
future.
Differential Revision: https://reviews.llvm.org/D26698
llvm-svn: 287152
This is forcing to use Error::success(), which is in a wide majority
of cases a lot more readable.
Differential Revision: https://reviews.llvm.org/D26481
llvm-svn: 286561
The mock server was listening for only one packet (I forgot to put a loop around
it), which caused the client to stall in debug builds, as the timeout there is
1000 seconds. In case of a release builds the test would just silently succeed as
the tested function does not check or report errors (which should be fixed).
This fixes the test by adding the server loop. Since the test was taking quite a
long time now (8s), I have added a parameter to control the amount of data sent
(default 4MB), and call it with a smaller value in the test, to make the test run
faster.
llvm-svn: 285992
I did not take into account that the output of the Dump function will be
non-deterministic. Fix that by increasing of the times, this also makes the test
check that the dump function sorts the output.
llvm-svn: 285892
Summary:
While removing TimeValue from this class I noticed a lot of room for small
simplifications here. Main are:
- instead of complicated start-stop dances to compute own time, each Timer
just starts the timer once, and keeps track of the durations of child
timers. Then the own time can be computed at the end by subtracting the two
values.
- remove double accounting in TimerStack - the stack object already knows the
number of timers.
The interface does not lend itself well to unit testing, but I have added a
couple of tests which can (and did) catch any obvious errors.
Reviewers: tberghammer, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D26243
llvm-svn: 285890
Include the gtest utility directory from LLVM sources when performing
a stand-alone build of LLDB. This is necessary to have a correct gtest
library to link tests against, as the one used by LLVM is not installed
(and not supposed to be). This is the same approach as used in clang.
Differential Revision: https://reviews.llvm.org/D26245
llvm-svn: 285865
Summary:
The only usage there was in GetModificationTime(). I also took the opportunity
to move this function from FileSpec to the FileSystem class - since we are
using FileSpecs to also represent remote files for which we cannot (easily)
retrieve modification time, it makes sense to make the decision to get the
modification time more explicit.
The new function returns a llvm::sys::TimePoint<>. To aid the transition
from TimeValue, I have added a constructor to it which enables implicit
conversion from a time_point.
Reviewers: zturner, clayborg
Subscribers: mehdi_amini, tberghammer, danalbert, beanz, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D25392
llvm-svn: 285702
for floating point registers was not recording them correctly. I needed to
change the EmulateInstructionARM64 unwind plans from using the DWARF
register numbering scheme to using the LLDB register numbering scheme
(because dwarf doesn't define register numbers for the 64-bit "d" registers).
Updated the EmulateInstructionARM64 unit tests to work with the LLDB
register numbering scheme and added a unit test to check the floating
point register spills & restores are correctly recorded.
https://reviews.llvm.org/D25864
<rdar://problem/28745483>
llvm-svn: 285662
Summary:
Most of the changes are very straight-forward, the only tricky part was the
"packet speed-test" function, which is very time-heavy. As the function was
completely untested, I added a quick unit smoke test for it.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D25391
llvm-svn: 285602
Summary:
.. handling for windows path was completely broken because the function was
expecting \ as path separators, but we were passing it normalized file paths,
where these have been replaced by forward slashes. Apart from this, the function
was incorrect for posix paths as well in some corner cases, as well as being
generally hard to follow.
The corner cases were:
- /../bar -> should be same as /bar
- /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually
existing, but since we're doing it in an abstract way, I think the
transformation is reasonable)
I rewrite the function to fix these corner cases and handle windows paths more
correctly. The function should now handle the posix paths (modulo symlinks, but
we cannot really do anything about that without a real filesystem). For windows
paths, there are a couple of corner cases left, mostly to do with drive letter
handling, which cannot be fixed until the rest of the class understands drive
letters better.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D26081
llvm-svn: 285593
Summary:
This plugin resembles the already existing Windows-only Minidump plugin.
The WinMinidumpPlugin uses the Windows API for parsing Minidumps
while this plugin is cross-platform because it includes a Minidump
parser (which is already commited)
It is able to produce a backtrace, to read the general puprose regiters,
inspect local variables, show image list, do memory reads, etc.
For now the only arches that this supports are x86_32 and x86_64.
This is because I have only written register contexts for those.
Others will come in next CLs.
I copied the WinMinidump tests and adapted them a little bit for them to
work with the new plugin (and they pass)
I will add more tests, aiming for better code coverage.
There is still functionality to be added, see TODOs in code.
Reviewers: labath, zturner
Subscribers: beanz, mgorny, modocache, lldb-commits, amccarth
Differential Revision: https://reviews.llvm.org/D25905
llvm-svn: 285587
Summary:
This, like the x86_64 case, reads the register values from the minidump
file, and emits a binary buffer that is ordered using the offsets from
the RegisterInfoInterface argument. That way we can reuse an existing
register context.
Added unit tests.
Reviewers: labath, zturner
Subscribers: beanz, mgorny, modocache, amccarth, lldb-commits
Differential Revision: https://reviews.llvm.org/D25832
llvm-svn: 285584
Most of them fail right now and are commented out. The main problem is handling
of backslashes on windows, but also the posix path code has a couple of issues.
llvm-svn: 285393
Summary:
Now the Minidump parser can parse the:
1) MemoryInfoList - containing region info about memory ranges (readable,
writable, executable)
2) Memory64List - this is the stuct used when the Minidump is a
full-memory one.
3) Adding filtering of the module list (shared libraries list) - there
can be mutliple records in the module list under the same name but with
different load address (e.g. when the binary has non contigious
sections). FilterModuleList eliminates the duplicated modules, leaving
the one with the lowest load addr.
Added unit tests for everything.
Reviewers: labath, zturner
Subscribers: beanz, mgorny, modocache, lldb-commits, amccarth
Differential Revision: https://reviews.llvm.org/D25569
llvm-svn: 284593
prologue, then loads & stores x20 on the stack from a different
location in the middle of the function, and then restores the
reg in the epilogue. The saving/restoring of x20 in the middle
of the function should be ignored.
llvm-svn: 283969
MSVC does not like the declaration of a terminate() function (I guess it looks
too much like std::terminate()). While I'm there, move the setup/teardown code
into the functions gtest provides for that purpose.
llvm-svn: 283870
plan generator.
Fix a small bug in EmulateInstructionARM64::GetFramePointerRegister
which was returning the stack pointer reg instead of fp, prevented
the unwinder from recognizing the switch to using the fp in a
function. (<rdar://problem/28663117>)
Add a new eContextRestoreStackPointer context hint so that the arm64
emulator can flag when the frame pointer value is copied back in to
the stack pointer and that should be used to compute the canonical
frame address again in an epilogue sequence. (<rdar://problem/28704862>)
Small changes to UnwindAssemblyInstEmulation to have a method we can
call without a live process/thread/etc for unit tests.
<rdar://problem/28663117>
<rdar://problem/28704862>
<rdar://problem/28509178>
llvm-svn: 283847
insturction profiling. Add a test that verifies that we reject a
32-bit only instruction in 64-bit (long) mode.
This wraps up all the testing I want to add for
x86AssemblyInspectionEngine.
llvm-svn: 283404
Tests are failing and build is failing on windows and darwin.
Will fix and commit it later
-------------------------------------------------------------
Revert "xfailing minidump tests again ... :("
This reverts commit 97eade002c9e43c1e0d11475a4888083a8965044.
Revert "Fixing new Minidump plugin tests"
This reverts commit 0dd93b3ab39c8288696001dd50b9a093b813b09c.
Revert "Add the new minidump files to the Xcode project."
This reverts commit 2f638a1d046b8a88e61e212220edc40aecd2ce44.
Revert "xfailing tests for Minidump plugin"
This reverts commit 99311c0b22338a83e6a00c4fbddfd3577914c003.
Revert "Adding a new Minidump post-mortem debugging plugin"
This reverts commit b09a7e4dae231663095a84dac4be3da00b03a021.
llvm-svn: 283352
Summary:
This plugin resembles the already existing Windows-only Minidump plugin.
The WinMinidumpPlugin uses the Windows API for parsing Minidumps
while this plugin is cross-platform because it includes a Minidump
parser (which is already commited)
It is able to produce a backtrace, to read the general puprose regiters,
inspect local variables, show image list, do memory reads, etc.
For now the only arch that this supports is x86 64 bit
This is because I have only written a register context for that arch.
Others will come in next CLs.
I copied the WinMinidump tests and adapted them a little bit for them to
work with the new plugin (and they pass)
I will add more tests, aiming for better code coverage.
There is still functionality to be added, see TODOs in code.
Reviewers: labath, zturner
Subscribers: beanz, mgorny, amccarth, lldb-commits, modocache
Differential Revision: https://reviews.llvm.org/D25196
llvm-svn: 283259
unittests. If I have time, I'd like to see if I can write some
tests of the eh_frame augmentation which is a wholly separate code
path (it seems like maybe it should be rolled into the main instruction
scanning codepath, to be honest, and operate on the generated
UnwindPlan instead of bothering with raw instructions at all).
Outside the eh_frame augmentation, I'm comfortable that this unwind
generator is being tested well now.
llvm-svn: 283186
There were a number of issues with the Args class preventing
efficient use of strings and incoporating LLVM's StringRef class.
The two biggest were:
1. Backing memory stored in a std::string, so we would frequently
have to use const_cast to get a mutable buffer for passing to
various low level APIs.
2. backing std::strings stored in a std::list, which doesn't
provide random access.
I wanted to solve these two issues so that we could provide
StringRef access to the underlying arguments, and also a way
to provide range-based access to the underlying argument array
while still providing convenient c-style access via an argv style
const char**.
The solution here is to store arguments in a single "entry" class
which contains the backing memory, a StringRef with precomputed
length, and the quote char. The backing memory is a manually
allocated const char* so that it is not invalidated when the
container is resized, and there is a separate argv array provided
for c-style access.
Differential revision: https://reviews.llvm.org/D25099
llvm-svn: 283157
assembly inspection class is designed to detect. This is only about
half of the instructions that it needs to recognize - I'll complete
this in a separate checkin.
The larger full-function style test cases I'd checked in previously
covered nearly all of these already, but I wanted simpler test cases
too, so if they fail in the future, it will be easier to spot the
issue.
llvm-svn: 283010
'push 0x20(%esp)' which clang can generate when emitting
-fomit-frame-pointer code for 32-bit.
Add a unit test program which includes this instruction.
Also fix a bug in the refactoring/rewrite of the x86 assembly
instruction profiler where I'd hard coded it as a 64-bit disassembler
instead of using the ArchSpec to pick a 32-bit or 64-bit disassembler
from llvm. When the disassembler would hit an instruction
that is invalid in 64-bit mode, it would stop disassembling the function.
This likely led to the TestSBData testsuite failure on linux with 32-bit
i386 and gcc-4.9; I'll test that in a bit.
The newly added unit test program is 32-bit i386 code and it includes
an instruction which is invalid in 64-bit mode so it will catch this.
<rdar://problem/28557876>
llvm-svn: 282991
a large stack frame with lots of spilled registers.
While writing the i386 version of this test, it looks
like I found a bug in the 32-bit instruction profiler
code. I may ned to fix the assembly inspection engine
before I can finish writing that test, so I'm only
committing the 64-bit one tonight.
<rdar://problem/28509178>
llvm-svn: 282683
a linux bot test failure. That one is fixed; hopefully there won't
be any others turned up this time.
The eh_frame augmentation code wasn't working right after the
reorg/rewrite of the classes. It works correctly now for the one
test that was failing - but we'll see what the test bots come up
with.
<rdar://problem/28509178>
llvm-svn: 282659
A testbot found a regression introduced in the testsuite with
the changes in r282565 on Ubuntu (TestStepNoDebug.ReturnValueTestCase).
I'll get this set up on an ubuntu box and figure out what is happening
there -- likely a problem with the eh_frame augmentation, which isn't
used on macosx.
llvm-svn: 282566
x86AssemblyInspectionEngine and the current UnwindAssembly_x86 to
allow for the core engine to be exercised by unit tests.
The UnwindAssembly_x86 class will have access to Targets, Processes,
Threads, RegisterContexts -- it will be working in the full lldb
environment.
x86AssemblyInspectionEngine is layered away from all of that, it is
given some register definitions and a bag of bytes to profile.
I wrote an initial unittest for a do-nothing simple x86_64/i386
function to start with. I'll be adding more.
The x86 assembly unwinder was added to lldb early in its bringup;
I made some modernization changes as I was refactoring the code
to make it more consistent with how we write lldb today.
I also added RegisterContextMinidump_x86_64.cpp to the xcode project
file so I can run the unittests from that.
The testsuite passes with this change, but there was quite a bit of
code change by the refactoring and it's possible there are some
issues. I'll be testing this more in the coming days, but it looks
like it is behaving correctly as far as I can tell with automated
testing.
<rdar://problem/28509178>
llvm-svn: 282565
Summary:
This is a register context converter from Minidump to Linux reg context.
This knows the layout of the register context in the Minidump file
(which is the same as in Windows FYI) and as a result emits a binary data
buffer that matches the Linux register context binary layout.
This way we can reuse the existing RegisterContextLinux_x86_64 and
RegisterContextCorePOSIX_x86_64 classes.
Reviewers: labath, zturner
Subscribers: beanz, mgorny, lldb-commits, amccarth
Differential Revision: https://reviews.llvm.org/D24919
llvm-svn: 282529
Also fixed up a couple misbehaving functions. It is perfectly
legal to have env vars with no values (i.e. the '=' and following
need not be present).
llvm-svn: 282171
The test exposed a bug in the StructuredData Serialization code, which did not
escape the backslash properly. This manifested itself as windows breakpoint
serialization roundtrip test not succeeding (as windows paths included
backslashes).
llvm-svn: 282167
This patch also marks the const char* versions as =delete to prevent
their use. This has the potential to cause build breakages on some
platforms which I can't compile. I have tested on Windows, Linux,
and OSX. Best practices for fixing broken callsites are outlined in
Args.h in a comment above the deleted function declarations.
Eventually we can remove these =delete declarations, but for now they
are important to make sure that all implicit conversions from
const char * are manually audited to make sure that they do not invoke a
conversion from nullptr.
llvm-svn: 281919
Where possible, remove the const char* version. To keep the
risk and impact here minimal, I've only done the simplest
functions.
In the process, I found a few opportunities for adding some
unit tests, so I added those as well.
Tested on Windows, Linux, and OSX.
llvm-svn: 281799
This makes the code easier to grok, and since this is a very low
level function it also is very helpful to have this take a StringRef
since it means anyone higher up the chain who has a StringRef would
have to first convert it to a null-terminated string. This way it
can work equally well with StringRefs or const char*'s, which will
enable the conversion of higher up functions to StringRef.
Tested on Windows, Linux, and OSX and saw no regressions.
llvm-svn: 281642
I'm was trying to do some cleanup and code modernization and in
doing so I needed to change ParseMachCPUDashSubtypeTriple to take
a StringRef. To ensure I don't break anything, I'm adding some
unit tests for this function. As a side benefit, this also expands
test coverage of this function to all platforms, since in general
this code would rarely be exercised on non Mac platforms, and never
in the test suite.
llvm-svn: 281387
Summary:
Added parsing of the MiscInfo data stream.
The main member of it that we care about is the process_id
On Linux generated Minidump (from breakpad) we don't have
the MiscInfo, we have the /proc/$pid/status from where we can get the
pid.
Also parsing the module list - the list of all of the loaded
modules/shared libraries.
Parsing the exception stream.
Parsing MinidumpStrings.
I have unit tests for all of that.
Also added some tests using a Minidump generated from Windows tools (not
from breakpad)
Reviewers: labath, zturner
Subscribers: beanz, lldb-commits
Differential Revision: https://reviews.llvm.org/D24385
llvm-svn: 281348
This change does the following:
* Changes the signature for the continuation delegate method that handles
async structured data from accepting an already-parsed structured data
element to taking just the packet contents.
* Moves the conversion of the JSON-async: packet contents from
GDBRemoteClientBase to the continuation delegate method.
* Adds a new unit test for verifying that the $JSON-asyc: packets get
decoded and that the decoded packets get forwarded on to the delegate
for further processing. Thanks to Pavel for making that whole section of
code easily unit testable!
* Tightens up the packet verification on reception of a $JSON-async:
packet contents. The code prior to this change is susceptible to a
segfault if a packet is carefully crafted that starts with $J but
has a total length shorter than the length of "$JSON-async:".
Reviewers: labath, clayborg, zturner
Differential Revision: https://reviews.llvm.org/D23884
llvm-svn: 281121
The behaviour of FileSpec differed between host OS versions. Hardcode the path
syntax to posix, as we don't care about that in this test.
llvm-svn: 281025
Summary:
This adds the jModulesInfo packet, which is the equivalent of qModulesInfo, but it enables us to
query multiple modules at once. This makes a significant speed improvement in case the
application has many (over a hundred) modules, and the communication link has a non-negligible
latency. This functionality is accessed by ProcessGdbRemote::PrefetchModuleSpecs(), which does
the caching. GetModuleSpecs() is modified to first consult the cache before asking the remote
stub. PrefetchModuleSpecs is currently only called from POSIX-DYLD dynamic loader plugin, after
it reads the list of modules from the inferior memory, but other uses are possible.
This decreases the attach time to an android application by about 40%.
Reviewers: clayborg
Subscribers: tberghammer, lldb-commits, danalbert
Differential Revision: https://reviews.llvm.org/D24236
llvm-svn: 280919
After the reformat, the unittests do not compile due to missing due to redefinition errors
between PosixApi.h and ucrt/direct.h. This is a bit of a shot in the dark, as I have not tested
it on windows, but I am restoring the original include order, so it should hopefully fix it.
llvm-svn: 280793
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
this is a resubmission of r280476. The problem with the original commit was that it was printing
out all numbers as signed, which was wrong for unsigned numbers with the MSB set. Fix that and
add a unit test covering that case.
llvm-svn: 280480
This reverts commit r280476 as it breaks several tests on i386. I was fixing an 32-bit
breakage, and I did not run the 32-bit test suite before submitting, oops.
llvm-svn: 280478
Summary:
It seems the original intention of the function was printing signed values in decimal format, and
unsigned values in hex (without the leading "0x"). However, signed and unsigned long were
exchanged, which lead to amusing test failures in TestMemoryFind.py.
Instead of just switching the two, I think we should just print everything in decimal here, as
the current behaviour is very confusing (especially when one does not request printing of types).
Nothing seems to depend on this behaviour except and we already have a way for the user to
request the format he wants when printing values for most commands (which presumably does not go
through this function).
I also add a unit tests for the function in question.
Reviewers: clayborg, granata.enrico
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24126
llvm-svn: 280476
Summary:
This is a Minidump parsing code.
There are still some more structures/data streams that need to be added.
The aim ot this is to be used in the implementation of
a minidump debugging plugin that works on all platforms/architectures.
Currently we have a windows-only plugin that uses the WinAPI to parse
the dump files.
Also added unittests for the current functionality.
Reviewers: labath, amccarth
Subscribers: tberghammer, danalbert, srhines, lldb-commits, dschuff
Differential Revision: https://reviews.llvm.org/D23545
llvm-svn: 280356
The rewrite of StringExtractor::GetHexMaxU32 changes functionality in a way which makes
lldb-server crash. The crash (assert) happens when parsing the "qRegisterInfo0" packet, because
the function tries to drop_front more bytes than the packet contains. It's not clear to me
whether we should consider this a bug in the caller or the callee, but it any case, it worked
before, so I am reverting this until we can figure out what the proper interface should be.
llvm-svn: 280207
Makes Peek() return a StringRef instead of a const char*.
This leads to a few callers of Peek() being able to be made a
little nicer (for example using StringRef member functions instead
of c-style strncmp and related functions) and generally safer
usage.
llvm-svn: 280139
This is a NFC that adds more unit test coverage of the GetHex***
functions as well as the functions to extract numbers with a
specific endianness.
llvm-svn: 280124
MutableArrayRef<T> is essentially a safer version of passing around
(T*, length) pairs and provides some convenient functions for working
with the data without having to manually manipulate indices.
This is a minor NFC.
llvm-svn: 280123
StringExtractor::GetNameColonValue() looks for a substring of the
form "<name>:<value>" and returns <name> and <value> to the caller.
This results in two unnecessary string copies, since the name and
value are not translated in any way and simply returned as-is.
By converting this to return StringRefs we can get rid of hundreds
of string copies.
llvm-svn: 280000
These are helpful on their own, but will be even more useful
once the GetNameColonValue is updated to return StringRefs
instead of std::strings.
llvm-svn: 279919
This started as an effort to change StringExtractor to store a
StringRef internally instead of a std::string. I got that working
locally with just 1 test failure which I was unable to figure out the
cause of. But it was also a massive changelist due to a trickle
down effect of changes.
So I'm starting over, using what I learned from the first time to
tackle smaller, more isolated changes hopefully leading up to
a full conversion by the end.
At first the changes (such as in this CL) will seem mostly
a matter of preference and pointless otherwise. However, there
are some places in my larger CL where using StringRef turned 20+
lines of code into 2, drastically simplifying logic. Hopefully
once these go in they will illustrate some of the benefits of
thinking in terms of StringRef.
llvm-svn: 279917
Summary:
This is a preparatory commit for D22914, where I'd like to replace this mutex by an R/W lock
(which is also not recursive). This required a couple of changes:
- The only caller of Read/WriteRegister, GDBRemoteRegisterContext class, was already acquiring
the mutex, so these functions do not need to. All functions which now do not take a lock, take
an lock argument instead, to remind the caller of this fact.
- GetThreadSuffixSupported() was being called from locked and unlocked contexts (including
contexts where the process was running, and the call would fail if it did not have the result
cached). I have split this into two functions, one which computes the thread suffix support and
caches it (this one always takes the lock), and another, which returns the cached value (and
never needs to take the lock). This feels quite natural as ProcessGdbRemote was already
pre-caching this value at the start.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23802
llvm-svn: 279725
Summary:
The tricky part here was that the exisiting implementation of WriteAllRegisters was expecting
hex-encoded data (as that was what the first implementation I replaced was using, but here we had
binary data to begin with. I thought the read/write register functions would be more useful if
they handled the hex-encoding themselves (all the other client functions provide the responses in
a more-or-less digested form). The read functions return a DataBuffer, so they can allocate as
much memory as they need to, while the write functions functions take an llvm::ArrayRef, as that
can be constructed from pretty much anything.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23659
llvm-svn: 279232
This change adds the Process/gdb-remote gtests to the Xcode
build. It also adds a virtual method impl to the continuation
delegate that I added with the StructuredDataPlugin change.
llvm-svn: 279203
Summary:
Before this, each function had a copy of the code which handled appending of the thread suffix to
the packet (or using $Hg instead). I have moved that code into a single function and made
everyone else use that. The function takes the partial packet as a StreamString rvalue reference,
to avoid a copy and to remind the users that the packet will have undeterminate contents after
the call.
This also fixes the incorrect formatting of the QRestoreRegisterState packet in case thread
suffix is not supported.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23604
llvm-svn: 279040
Summary:
CPlusPlusLanguage::MethodName was not correctly parsing templated functions whose demangled name
included the return type -- the space before the function name was included in the "context" and
the context itself was not terminated correctly due to a misuse of the substr function (second
argument is length, not the end position). Fix that and add a regression test.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23608
llvm-svn: 279038
Apparently clang will happily capture a const variable in a lambda without it being specified in
the capture clause. MSVC does not like that.
llvm-svn: 278925
Summary:
When saving/restoring registers the GDBRemoteRegisterContext class was manually constructing
the register save/restore packets. This creates appropriate helper functions in
GDBRemoteCommunicationClient, and switches the class to use those. It also removes what a
duplicate packet send in some of those functions, a thing that I can only attribute to a bad
merge artefact.
I also add a test framework for testing gdb-remote client functionality and add tests for the new
functions I introduced. I'd like to be able to test the register context changes in isolation as
well, but currently there doesn't seem to be a way to reasonably construct a standalone register
context object, so we'll have to rely on the end-to-end tests to verify that.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23553
llvm-svn: 278915
Despite its comment, the function is only used in the Client class, and its presence was merely
complicating mock implementation in unit tests.
llvm-svn: 278785
Summary:
The following problem was occuring:
- broadcaster B had two listeners: L1 and L2 (thread T1)
- (T1) B has started to broadcast an event, it has locked a shared_ptr to L1 (in
ListenerIterator())
- on another thread T2 the penultimate reference to L1 was destroyed (the transient object in B is
now the last reference)
- (T2) the last reference to L2 was destroyed as well
- (T1) B has finished broadcasting the event to L1 and destroyed the last shared_ptr
- (T1) this triggered the destructor, which called into B->RemoveListener()
- (T1) all pointers in the m_listeners list were now stale, so RemoveListener emptied the list
- (T1) Eventually control returned to the ListenerIterator() for doing broadcasting, which was
still in the middle of iterating through the list
- (T1) Only now, it was holding onto a dangling iterator. BOOM.
I fix this issue by making sure nothing can interfere with the
iterate-and-remove-expired-pointers loop, by moving this logic into a single function, which
first locks (or clears) the whole list and then returns the list of valid and locked Listeners
for further processing. Instead of std::list I use an llvm::SmallVector which should hopefully
offset the fact that we create a copy of the list for the common case where we have only a few
listeners (no heap allocations).
A slight difference in behaviour is that now RemoveListener does not remove an element from the
list -- it only sets it's mask to 0, which means it will be removed during the next iteration of
GetListeners(). This is purely an implementation detail and it should not be externally
noticable.
I was not able to reproduce this bug reliably without inserting sleep statements into the code,
so I do not add a test for it. Instead, I add some unit tests for the functions that I do modify.
Reviewers: clayborg, jingham
Subscribers: tberghammer, lldb-commits
Differential Revision: https://reviews.llvm.org/D23406
llvm-svn: 278664
Resumbitting the commit after fixing the following problems:
- broken unit tests on windows: incorrect gtest usage on my part (TEST vs. TEST_F)
- the new code did not correctly handle the case where we went to interrupt the process, but it
stopped due to a different reason - the interrupt request would remain queued and would
interfere with the following "continue". I also added a unit test for this case.
This reapplies r277156 and r277139.
llvm-svn: 278118
This reverts commit r277139, because:
- broken unittest on windows (likely typo on my part)
- seems to break TestCallThatRestart (needs investigation)
llvm-svn: 277154
SendContinuePacketAndWaitForResponse was huge function with very complex interactions with
several other functions (SendAsyncSignal, SendInterrupt, SendPacket). This meant that making any
changes to how packet sending functions and threads interact was very difficult and error-prone.
This change does not add any functionality yet, it merely paves the way for future changes. In a
follow-up, I plan to add the ability to have multiple query packets in flight (i.e.,
request,request,response,response instead of the usual request,response sequences) and use that
to speed up qModuleInfo packet processing.
Here, I introduce two special kinds of locks: ContinueLock, which is used by the continue thread,
and Lock, which is used by everyone else. ContinueLock (atomically) sends a continue packet, and
blocks any other async threads from accessing the connection. Other threads create an instance of
the Lock object when they want to access the connection. This object, while in scope prevents the
continue from being send. Optionally, it can also interrupt the process to gain access to the
connection for async processing.
Most of the syncrhonization logic is encapsulated within these two classes. Some of it still
had to bleed over into the SendContinuePacketAndWaitForResponse, but the function is still much
more manageable than before -- partly because of most of the work is done in the ContinueLock
class, and partly because I have factored out a lot of the packet processing code separate
functions (this also makes the functionality more easily testable). Most importantly, there is
none of syncrhonization code in the async thread users -- as far as they are concerned, they just
need to declare a Lock object, and they are good to go (SendPacketAndWaitForResponse is now a
very thin wrapper around the NoLock version of the function, whereas previously it had over 100
lines of synchronization code). This will make my follow up changes there easy.
I have written a number of unit tests for the new code and I have ran the test suite on linux and
osx with no regressions.
Subscribers: tberghammer
Differential Revision: https://reviews.llvm.org/D22629
llvm-svn: 277139
Summary:
The function was returning the null pointer for peeks of size zero, which seems like a sensible
thing to do, but is actually pretty easy to get bitten by that if you are extracting a variable
length field which happens to be of zero length and then doing pointer arithmetic on that (which
SymbolFileDWARF does, and ended up crashing in case of empty DW_AT_location).
This changes the function to return a null pointer only when it gets queried for data which is
outside of the range of the extractor, which is more c++-y, as one can still do reasonable things
with pointers to data of size zero (think, end() iterators).
I also add a test and fix some signedness warnings in the existing data extractor tests.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22755
llvm-svn: 276734
Summary: One of the cases handled by ValueObjectChild::UpdateValue() uses the entire width of the parent's scalar value as the size of the child, and extracts the child by calling Scalar::ExtractBitfield(). This seems valid but APInt::trunc(), APInt::sext() and APInt::zext() assert that the bit field must not have the same size as the parent scalar. Replacing those calls with sextOrTrunc(), zextOrTrunc(), sextOrSelf() and zextOrSelf() fixes the assertion failures.
Reviewers: uweigand, labath
Subscribers: labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D20355
llvm-svn: 270062
Summary:
AdbClient was attempting to handle the case where the socket input arrived in pieces, but it was
failing to handle the case where the connection was closed before that happened. In this case, it
would just spin in an infinite loop calling Connection::Read. (This was also the cause of the
spurious timeouts on the darwin->android buildbot. The exact cause of the premature EOF remains
to be investigated, but is likely a server bug.)
Since this wait-for-a-certain-number-of-bytes seems like a useful functionality to have, I am
moving it (with the infinite loop fixed) to the Connection class, and adding an
appropriate test for it.
Reviewers: clayborg, zturner, ovyalov
Subscribers: tberghammer, danalbert, lldb-commits
Differential Revision: http://reviews.llvm.org/D19533
llvm-svn: 268380
Recommit modified version of r266311 including build bot regression fix.
This differs from the original r266311 by:
- Fixing Scalar::Promote to correctly zero- or sign-extend value depending
on signedness of the *source* type, not the target type.
- Omitting a few stand-alone fixes that were already committed separately.
llvm-svn: 266422
This implements a PDBASTParser and corresponding logic in
SymbolFilePDB to do type lookup by name. This is just a first
pass and leaves many aspects of type lookup unimplemented, and
just focuses on laying the framework. With this patch, you should
be able to lookup basic types by name from a PDB.
Full class definitions are not completed yet, we will instead
just return a forward declaration of the class.
Differential Revision: http://reviews.llvm.org/D18848
Reviewed by: Greg Clayton
llvm-svn: 266392
Currently, the DataExtractor::GetMaxU64Bitfield and GetMaxS64Bitfield
routines assume the incoming "bitfield_bit_offset" parameter uses
little-endian bit numbering, i.e. a bitfield_bit_offset 0 refers to
a bitfield whose least-significant bit coincides with the least-
significant bit of the surrounding integer.
On many big-endian systems, however, the big-endian bit numbering
is used for bit fields. Here, a bitfield_bit_offset 0 refers to
a bitfield whose most-significant bit conincides with the most-
significant bit of the surrounding integer.
Now, in principle LLDB could arbitrarily choose which semantics of
bitfield_bit_offset to use. However, there are two problems with
the current approach:
- When parsing DWARF, LLDB decodes bit offsets in little-endian
bit numbering on LE systems, but in big-endian bit numbering
on BE systems. Passing those offsets later on into the
DataExtractor routines gives incorrect results on BE.
- In the interim, LLDB's type layer combines byte and bit offsets
into a single number. I.e. instead of recording bitfields by
specifying the byte offset and byte size of the surrounding
integer *plus* the bit offset of the bit field within that field,
it simply records a single bit offset number.
Now, note that converting from byte offset + bit offset to a
single offset value and back is well-defined if we either use
little-endian byte order *and* little-endian bit numbering,
or use big-endian byte order *and* big-endian bit numbering.
Any other combination will yield incorrect results.
Therefore, the simplest approach would seem to be to always use
the bit numbering that matches the system byte order. This makes
storing a single bit offset valid, and makes the existing DWARF
code correct. The only place to fix is to teach DataExtractor
to use big-endian bit numbering on big endian systems.
However, there is only additional caveat: we also get bit offsets
from LLDB synthetic bitfields. While the exact semantics of those
doesn't seem to be well-defined, from test cases it appears that
the intent was for the user-provided synthetic bitfield offset to
always use little-endian bit numbering. Therefore, on a big-endian
system we now have to convert those to big-endian bit numbering
to remain consistent.
Differential Revision: http://reviews.llvm.org/D18982
llvm-svn: 266312
The Scalar implementation and a few other places in LLDB directly
access the internal implementation of APInt values using the
getRawData method. Unfortunately, pretty much all of these places
do not handle big-endian systems correctly. While on little-endian
machines, the pointer returned by getRawData can simply be used as
a pointer to the integer value in its natural format, no matter
what size, this is not true on big-endian systems: getRawData
actually points to an array of type uint64_t, with the first element
of the array always containing the least-significant word of the
integer. This means that if the bitsize of that integer is smaller
than 64, we need to add an offset to the pointer returned by
getRawData in order to access the value in its natural type, and
if the bitsize is *larger* than 64, we actually have to swap the
constituent words before we can access the value in its natural type.
This patch fixes every incorrect use of getRawData in the code base.
For the most part, this is done by simply removing uses of getRawData
in the first place, and using other APInt member functions to operate
on the integer data.
This can be done in many member functions of Scalar itself, as well
as in Symbol/Type.h and in IRInterpreter::Interpret. For the latter,
I've had to add a Scalar::MakeUnsigned routine to parallel the existing
Scalar::MakeSigned, e.g. in order to implement an unsigned divide.
The Scalar::RawUInt, Scalar::RawULong, and Scalar::RawULongLong
were already unused and can be simply removed. I've also removed
the Scalar::GetRawBits64 function and its few users.
The one remaining user of getRawData in Scalar.cpp is GetBytes.
I've implemented all the cases described above to correctly
implement access to the underlying integer data on big-endian
systems. GetData now simply calls GetBytes instead of reimplementing
its contents.
Finally, two places in the clang interface code were also accessing
APInt.getRawData in order to actually construct a byte representation
of an integer. I've changed those to make use of a Scalar instead,
to avoid having to re-implement the logic there.
The patch also adds a couple of unit tests verifying correct operation
of the GetBytes routine as well as the conversion routines. Those tests
actually exposed more problems in the Scalar code: the SetValueFromData
routine didn't work correctly for 128- and 256-bit data types, and the
SChar routine should have an explicit "signed char" return type to work
correctly on platforms where char defaults to unsigned.
Differential Revision: http://reviews.llvm.org/D18981
llvm-svn: 266311
Summary:
In D18689, I removed the call to Normalize() in FileSpec::SetFile, because it no longer seemed
needed, and it resolved a quirk in the FileSpec API (spec.GetCString() returnes a path with
backslashes, but spec.GetDirectory().GetCString() has forward slashes). This turned out to be a
problem because we would consider paths with different separators as different (which led to
unresolved breakpoints for instance).
Here, I am putting back in the call to Normalize() and adding a unittest for FileSpec::Equal. I
am commenting out the GetDirectory unittests until we figure out the what is the expected
behaviour here.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D19060
llvm-svn: 266286
Summary:
Even though FileSpec attempted to handle both kinds of path syntaxes (posix and windows) on both
platforms, it relied on the llvm path library to do its work, whose behavior differed on
different platforms. This led to subtle differences in FileSpec behavior between platforms. This
replaces the pieces of the llvm library with our own implementations. The functions are simply
copied from llvm, with #ifdefs replaced by runtime checks for ePathSyntaxWindows.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18689
llvm-svn: 265299
In doing so, two bugs were uncovered (and fixed). The first bug
is that ClangASTContext::RemoveFastQualifiers() was broken, and
was not removing fast qualifiers (or doing anything else for that
matter). The second bug is that UnifyAccessSpecifiers treated
AS_None asymmetrically, which is probably an edge case, but seems
like a bug nonetheless.
llvm-svn: 265200
On some versions of Windows, the address is returned as "::1", while on others it's
"0:0:...:0:1". Accept both versions, as they represent the same address.
llvm-svn: 264850
Summary:
This fixes a couple of corner cases in FileSpec, related to AppendPathComponent and
handling of root directory (/) file spec. I add a bunch of unit tests for the new behavior.
Summary of changes:
FileSpec("/bar").GetCString(): before "//bar", after "/bar".
FileSpec("/").CopyByAppendingPathComponent("bar").GetCString(): before "//bar", after "/bar".
FileSpec("C:", ePathSyntaxWindows).CopyByAppendingPathComponent("bar").GetCString(): before "C:/bar", after "C:\bar".
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18044
llvm-svn: 263207
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
Summary:
the python2 branch seems erroneous as it expected the object to be both a "String" and "Bytes".
Fix the expectation.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17545
llvm-svn: 261901
Summary: This also fixes an infinite recursion between lldb_private::operator>> () and Scalar::operator>>= ().
Reviewers: sagar, tberghammer, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16868
Patch by Marianne Mailhot-Sarrasin
llvm-svn: 260239
65535 is still a valid port. This should fix the android failures we were getting when we chose
to connect over 65535 to the remote lldb-server.
llvm-svn: 259638
This needs to be able to handle bytes, strings, and bytearray objects.
In Python 2 this was easy because bytes and strings are the same thing,
but in Python 3 the 2 cases need to be handled separately. So as not
to mix raw Python C API code with PythonDataObjects code, I've also
introduced a PythonByteArray class to PythonDataObjects to make the
paradigm used here consistent.
llvm-svn: 258741
Primarily a trial test for me to try out the
git clang-format integration. Works like a charm!
This change adds a gtest fixture for the EditlineTest
common setup and teardown code.
llvm-svn: 258565
This is a helper class which supports a number of
features including exception to string formatting with
backtrace handling and auto-restore of exception state
upon scope exit.
Additionally, unit tests are included to verify the
feature set of the class.
llvm-svn: 252994
This allows other potential unit test suites (of which one is
forthcoming in a subsequent patch) to re-use the same initialization
and teardown of the GIL.
llvm-svn: 252993
This adds PythonTuple and PythonCallable classes to PythonDataObjects.
Additionally, unit tests are provided that exercise this functionality,
including invoking manipulating and checking for validity of tuples,
and invoking and checking for validity of callables using a variety
of different syntaxes.
The goal here is to eventually replace the code in python-wrapper.swig
that directly uses the Python C API to deal with callables and name
resolution with this code that can be more easily tested and debugged.
llvm-svn: 252787
The Go interpreter doesn't JIT or use LLVM, so this also
moves all the JIT related code from UserExpression to a new class LLVMUserExpression.
Differential Revision: http://reviews.llvm.org/D13073
Fix merge
llvm-svn: 251820
These are two simple tests that make sure single line and
multiline content are processed and received by Editline.cpp.
Fancier tests to come...
llvm-svn: 251681
Also added a placeholder Editline gtest for some code that I'll add as soon
as I make sure this addition doesn't break any of the build bots.
This change also introduces some Xcode user-defined variables that I've used
to attempt to isolate the way Python is integrated into the build. I don't have
the rest of LLDB using it yet, I'm using the gtests as my guinea pig on that.
Currently these are:
PYTHON_FRAMEWORK_PATH
PYTHON_VERSION_MAJOR
PYTHON_VERSION_MINOR
I will convert the rest over to it after this gets a little time to bake
and any kinks are worked out of it.
llvm-svn: 251261
The purpose of the class is to make it easy to execute tasks in parallel
Basic design goals:
* Have a very lightweight and easy to use interface where a list of
lambdas can be executed in parallel
* Use a global thread pool to limit the number of threads used
(std::async don't do it on Linux) and to eliminate the thread creation
overhead
* Destroy the thread currently not in use to avoid the confusion caused
by them during debugging LLDB
Possible future improvements:
* Possibility to cancel already added, but not yet started tasks
* Parallel for_each implementation
* Optimizations in the thread creation destroyation code
Differential revision: http://reviews.llvm.org/D13727
llvm-svn: 250820
Python file handling got an overhaul in Python 3, and it affects
the way we have to interact with files. Notably:
1) `PyFile_FromFile` no longer exists, and instead we have to use
`PyFile_FromFd`. This means having a way to get an fd from
a FILE*. For this we reuse the lldb_private::File class to
convert between FILE*s and fds, since there are some subtleties
regarding ownership rules when FILE*s and fds refer to the same
file.
2) PyFile is no longer a builtin type, so there is no such thing as
`PyFile_Check`. Instead, files in Python 3 are just instances
of `io.IOBase`. So the logic for checking if something is a file
in Python 3 is to check if it is a subclass of that module.
Additionally, some unit tests are added to verify that `PythonFile`
works as expected on Python 2 and Python 3, and
`ScriptInterpreterPython` is updated to use `PythonFile` instead of
manual calls to the various `PyFile_XXX` methods.
llvm-svn: 250444
There were a couple of issues related to string handling that
needed to be fixed. In particular, we cannot get away with
converting `PyUnicode` objects to `PyBytes` objects and storing
the `PyBytes` regardless of Python version. Instead we have to
store a `PyUnicode` on Python 3 and a `PyString` on Python 2.
The reason for this is that if you call `PyObject_Str` on a
`PyBytes` in Python 3, it will return you a string that actually
contains the string value wrappedin the characters b''. So if we
create a `PythonString` with the value "test", and we call Str()
on it, we will get back the string "b'test'", which breaks string
equality. The only way to fix this is to store a native
`PyUnicode` object under Python 3.
With this CL, ScriptInterpreterPythonTests unit tests pass 100%
under Python 2 and Python 3.
llvm-svn: 250327
PythonObjects were being incorrectly ref-counted. This problem was
pervasive throughout the codebase, leading to an unknown number of memory
leaks and potentially use-after-free.
The issue stems from the fact that Python native methods can either return
"borrowed" references or "owned" references. For the former category, you
*must* incref it prior to decrefing it. And for the latter category, you
should not incref it before decrefing it. This is mostly an issue when a
Python C API method returns a `PyObject` to you, but it can also happen with
a method accepts a `PyObject`. Notably, this happens in `PyList_SetItem`,
which is documented to "steal" the reference that you give it. So if you
pass something to `PyList_SetItem`, you cannot hold onto it unless you
incref it first. But since this is one of only two exceptions in the
entire API, it's confusing and difficult to remember.
Our `PythonObject` class was indiscriminantely increfing every object it
received, which means that if you passed it an owned reference, you now
have a dangling reference since owned references should not be increfed.
We were doing this in quite a few places.
There was also a fair amount of manual increfing and decrefing prevalent
throughout the codebase, which is easy to get wrong.
This patch solves the problem by making any construction of a
`PythonObject` from a `PyObject` take a flag which indicates whether it is
an owned reference or a borrowed reference. There is no way to construct a
`PythonObject` without this flag, and it does not offer a default value,
forcing the user to make an explicit decision every time.
All manual uses of `PyObject` have been cleaned up throughout the codebase
and replaced with `PythonObject` in order to make RAII the predominant
pattern when dealing with native Python objects.
Differential Revision: http://reviews.llvm.org/D13617
Reviewed By: Greg Clayton
llvm-svn: 250195
With this change, liblldb is 95% of the way towards being able
to work under both Python 2.x and Python 3.x. This should
introduce no functional change for Python 2.x, but for Python
3.x there are some important changes. Primarily, these are:
1) PyString doesn't exist in Python 3. Everything is a PyUnicode.
To account for this, PythonString now stores a PyBytes instead
of a PyString. In Python 2, this is equivalent to a PyUnicode,
and in Python 3, we do a conversion from PyUnicode to PyBytes
and store the PyBytes.
2) PyInt doesn't exist in Python 3. Everything is a PyLong. To
account for this, PythonInteger stores a PyLong instead of a
PyInt. In Python 2.x, this requires doing a conversion to
PyLong when creating a PythonInteger from a PyInt. In 3.x,
there is no PyInt anyway, so we can assume everything is a
PyLong.
3) PyFile_FromFile doesn't exist in Python 3. Instead there is a
PyFile_FromFd. This is not addressed in this patch because it
will require quite a large change to plumb fd's all the way
through the system into the ScriptInterpreter. This is the only
remaining piece of the puzzle to get LLDB supporting Python 3.x.
Being able to run the test suite is not addressed in this patch.
After the extension module can compile and you can enter an embedded
3.x interpreter, the test suite will be addressed in a followup.
llvm-svn: 249886
Summary:
When `module_spec.GetFileSpec().GetDirectory().AsCString()` returned a `nullptr` this line caused a segmentation fault:
`std::string module_directory = module_spec.GetFileSpec().GetDirectory().AsCString()`
Some context:
I was remote debugging an executable built with Clang in an Ubuntu VM on my Windows machine using lldb-mi. I copied the executable and nothing else from the Ubuntu VM to the Windows machine.
Then started lldb-server in the Ubuntu VM:
```
./bin/lldb-server gdbserver *:8888 -- /home/enlight/Projects/dbgmits/build/Debug/data_tests_target
```
And ran `lldb-mi --interpreter` on Windows with the following commands:
```
-file-exec-and-symbols C:\Projects\data_tests_target
-target-select remote 192.168.56.101:8888
-exec-continue
```
After which the segmentation fault occurred at the aforementioned line. Inside this method `module_spec.GetFileSpec()` returns an empty `FileSpec` (no dir, no filename), while `module_spec.GetSymbolFileSpec().GetFilename()` returns `"libc-2.19.so"`.
Patch thanks to Vadim Macagon.
Reviewers: brucem, zturner, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13201
llvm-svn: 249387
Previously embedded interpreters were handled as ad-hoc source
files compiled into source/Interpreter. This made it hard to
disable a specific interpreter, or to add support for other
interpreters and allow the developer to choose which interpreter(s)
were enabled for a particular build.
This patch converts script interpreters over to a plugin-based system.
Script interpreters now live in source/Plugins/ScriptInterpreter, and
the canonical LLDB interpreter, ScriptInterpreterPython, is moved there
as well.
Any new code interfacing with the Python C API must live in this location
from here on out. Additionally, generic code should never need to
reference or make assumptions about the presence of a specific interpreter
going forward.
Differential Revision: http://reviews.llvm.org/D11431
Reviewed By: Greg Clayton
llvm-svn: 243681
Summary:
Fix StringExtractor.h issues.
* source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
(#include "Utility/StringExtractor.h): Not needed, this is already
included by ProcessKDP.h
* unittests/Utility/StringExtractorTest.cpp
(#include "Utility/StringExtractor.h): Update include path to the
new location.
Reviewers: labath, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10995
llvm-svn: 241596
Summary:
Since all TSC operations are now executed synchronously, TSC has become a little more than a
messenger between different parts of NativeProcessLinux. Therefore, the reason for its existance
has disappeared.
This commit moves the contents of the TSC into the NPL class. This will enable us to remove all
the boilerplate code in NPL (as it stands now, this is most of the class), which I plan to do in
subsequent commits.
Unfortunately, this also means we will lose the unit tests for the TSC. However, since the size
of the TSC has diminished, the unit tests were not testing much at this point anyway, so it's not
a big loss.
No functional change.
Test Plan: All tests continue to pass.
Reviewers: vharron, chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9296
llvm-svn: 236587
Summary:
This change removes the thread state coordinator thread by making all the operations it was
performing synchronous. In order to prevent deadlock, NativeProcessLinux must now always call
m_monitor->DoOperation with the m_threads_mutex released. This is needed because HandleWait
callbacks lock the mutex (which means the monitor thread will block waiting on whoever holds the
lock). If the other thread now requests a monitor operation, it will wait for the monitor thread
do process it, creating a deadlock.
To preserve this invariant I have introduced two new Monitor commands: "begin operation block"
and "end operation block". They begin command blocks the monitor from processing waitpid
events until the corresponding end command, thereby assuring the monitor does not attempt to
acquire the mutex.
Test Plan: Run the test suite locally, verify no tests fail.
Reviewers: vharron, chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9227
llvm-svn: 236501
Summary:
Currently, linking of the unittests fails on linux because it is missing a bunch of symbols from
libedit, curses, etc. This fixes the build by adding the correct dependencies.
Test Plan: Linking works, unit tests run.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9244
llvm-svn: 235853
The order of libraries passed to the linker didn't work under linux (you
need the llvm libraries first, then the lldb libraries). I modelled this
after clang's setup here. Seemed simple enough to just be consistent.
llvm-svn: 232461
A recent refactor had introduced a bug where if you escaped a
character, the rest of the string would get processed incorrectly.
This patch fixes that bug and adds some unit tests for Args.
llvm-svn: 232288
Sigh. There's really not a good alternative until we decouple
python from lldb better. The only way the build works right now
is by having every executable link against every LLDB library.
This causes implicit transitive link dependencies on the union
of everything that LLDB brings in. Which means that if all we
want is one header file from interpreter, we have to bring in
everything, including everything that everything depends on,
which means python.
There's outstanding efforts to address this, but it's not yet
complete. So until then, this is all we can do.
llvm-svn: 232287
On Windows, you need to call WSAStartup() before making any socket
calls, and WSACleanup() before you shutdown. This wasn't being
done, so all of the socket tests were failing. This fixes
that, which brings the unit test suite to a fully working state
on Windows.
llvm-svn: 232247
This makes the directory structure mirror the canonical LLVM
directory structure for a gtest suite.
Additionally, this patch deletes the xcode project. Nobody
is currently depending on this, and it would be better to have
gtest unit tests be hand-maintained in the Xcode workspace
rather than using this python test runner. Patches to that
effect will be submitted as followups.
llvm-svn: 232211
Davide Italiano