This is not ideal, but it should get the bot going again. I'll need to revisit this if we want to get signal handling working on Windows.
llvm-svn: 300587
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
r285226 dropped the code that did these checks. I am pretty
sure that was inadvertent, so I added that back in and added
a test for it.
<rdar://problem/31661252>
llvm-svn: 300564
The attribute was fairly dubious as: a) we shouldn't tell the compiler
when to inline functions, b) GCC complains that the function may be
not always inlinable.
llvm-svn: 300377
Summary:
This patch removes the hand maintained config files in favor of auto-generating the config file. We will still need to maintain the defines for the Xcode builds on Mac, but all CMake builds use the generated header instead.
This will enable finer grained platform support tests and enable supporting LLDB on more platforms with less manual maintenance.
I have only tested this patch on Darwin, and any help testing it out on other platforms would be greatly appreciated. I've probably messed something up somewhere.
Reviewers: labath, zturner
Reviewed By: labath
Subscribers: krytarowski, emaste, srhines, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D31969
llvm-svn: 300372
lldb should use when given a corefile.
This uses an LC_NOTE "main bin spec" or an LC_NOTE "kern ver str"
if they are present in a Mach-O core file.
Core files may have multiple different binaries -- different kernels,
or a mix of user process and kernel binaries -- and it can be
difficult for lldb to detect the correct one to use simply by looking
at the pages of memory. These two new LC_NOTE load commands allow
for the correct binary to be recorded unambiguously.
<rdar://problem/20878266>
llvm-svn: 300138
Summary: This patch adds a new wrapper for getaddrinfo which returns a std::vector of SocketAddresses. While this patch doesn't add any uses of the new function, I have two separable patches that are dependent on this, so I put it in its own patch.
Reviewers: zturner
Reviewed By: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31822
llvm-svn: 300112
Summary:
The iteration list through the available data formatters was undefined,
which meant that the vector<bool> formatter kicked in only in cases
where it happened to be queried before the general vector formatter. To
fix this, I merge the two data formatter entries into one, and select
which implementation to use in the factory function.
Reviewers: jasonmolenda, tberghammer, EricWF
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31880
llvm-svn: 300047
Summary:
The files there can always be referred to using their full path, which
is what most of the code has been doing already, so this makes the
situation more consistent. Also fix the the code in the FreeBSD plugin
to use the new paths.
Reviewers: eugene, emaste
Subscribers: lldb-commits, kettenis, mgorny, krytarowski
Differential Revision: https://reviews.llvm.org/D31877
llvm-svn: 299933
Summary:
This replaces old code in Host::GetEnvironment for NetBSD
with the version from Linux. This makes parsing environment
variables correctly. It also fixes programs that depend on the
variables like curses(3) applications.
Long term this function should be moved to Process Plugin,
as currently env variables are not available with remote
debugging.
Other BSDs might want to catch up after this change.
Tested with NetBSD top(1).
Sponsored by <The NetBSD Foundation>
Reviewers: emaste, labath, joerg, kettenis
Reviewed By: emaste
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31784
llvm-svn: 299783
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 adjusts header file includes for headers and source files
in Core. In doing so, one dependency cycle is eliminated
because all the includes from Core to that project were dead
includes anyway. In places where some files in other projects
were only compiling due to a transitive include from another
header, fixups have been made so that those files also include
the header they need. Tested on Windows and Linux, and plan
to address failures on OSX and FreeBSD after watching the
bots.
llvm-svn: 299714
This patch makes adjustments to header file includes in
lldbUtility based on recommendations by the iwyu tool
(include-what-you-use). The goal here is to make sure that
all files include the exact set of headers which are needed
for that file only, to eliminate cases of dead includes (e.g.
someone deleted some code but forgot to delete the header
includes that that code necessitated), and to eliminate the
case where header includes are picked up transitively.
llvm-svn: 299676
both sending and receiving information, instead of using one socket
to send and another to receive. The two socket arrangement fails over
when a firewall is between the two systems.
<rdar://problem/31286757>
llvm-svn: 299608
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
Change the get shared class info function to only
dump its results to the inferior stdout when the
log is verbose. This matches the lldb side of the
same process, which only logs what it found if the
log is on verbose.
llvm-svn: 299451
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:
Calling ValueObject::SetName from a sythetic child provider would change
the underying value object used for the non-synthetic child as well what
is clearly unintentional.
Reviewers: jingham, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31371
llvm-svn: 299259
Summary:
After this change a sythetic child provider can generate a special child
named "$$dereference$$" what if present is used when "operator*" or
"operator->" used on a ValueObject. The goal of the change is to make
expressions like "up->foo" work inside the "frame variable" command.
Reviewers: labath, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31368
llvm-svn: 299251
Summary:
Displaying the object pointed by the unique_ptr can cause an infinite
recursion when we have a pointer loop so this change stops that
behavior. Additionally it makes the unique_ptr act more like a class
containing a pointer (what is the underlying truth) instead of some
"magic" class.
Reviewers: labath, jingham
Differential Revision: https://reviews.llvm.org/D31366
llvm-svn: 299249
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
Summary:
Include initial support for:
- single step mode (PT_STEP)
- single step trap handling (TRAP_TRACE)
- exec() trap (TRAP_EXEC)
- add placeholder interfaces for FPR
- initial code for NetBSD core(5) files
- minor tweaks
While there improve style of altered elf-core/ files.
This code raises the number of passing tests on NetBSD to around 50% (600+/1200+).
The introduced code is subject to improve afterwards for additional features and bug fixes.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, emaste, kettenis
Reviewed By: labath
Subscribers: srhines, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31450
llvm-svn: 299109
Summary:
This patch is a stripped down from features a NetBSD process
code (patch is kept under 2k LOC). This code has assumption that
there is only one thread within a debugged process. The only
debugger trap supported is software breakpoint (TRAP_BRKPT).
The generic platform code requires to add dummy function for
watchpoints etc. These functions are currently empty.
This code is not the final platform support as is and it's treated as
a base to extend, refactor and address issues afterwards.
Supported features:
- handle software breakpoints,
- correctly attach to a tracee,
- support NetBSD specific ptrace(2),
- monitor process termination,
- monitor SIGTRAP events,
- monitor SIGSTOP events,
- monitor other signals events,
- resume the whole process,
- get memory region info perms,
- read memory from tracee,
- write memory to tracee,
- read ELF AUXV,
- x86_64 GPR read and write code
For the generic framework include:
- halt,
- detach,
- signal,
- kill,
- allocatememory,
- deallocatememory,
- update threads,
- getarchitecture,
- getfileloadaddress,
- and others.
This code has preliminary AddThread code.
Out of interest in this patch:
- exec() traps,
- hardware debug register traps,
- single step trap,
- thread creation/termination trap,
- process fork(2), vfork(2) and vfork(2) done traps,
- syscall entry and exit trap,
- threads,
- FPR registers,
- retrieving tracee's thread name,
- non x86_64 support.
This code can be used to start a hello world application and trace it.
This code can be used by other BSD systems as a starting point to get similar
capabilities.
Sponsored by <The NetBSD Foundation>
Reviewers: emaste, joerg, kettenis, labath
Subscribers: mgorny, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31374
llvm-svn: 298953
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
Summary:
Add basic OpenBSD support. This is enough to be able to analyze core dumps for OpenBSD/amd64, OpenBSD/arm, OpenBSD/arm64 and OpenBSD/i386.
Note that part of the changes to source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp fix a bug that probably affects other platforms as well. The GetProgramHeaderByIndex() interface use 1-based indices, but in some case when looping over the headers the, the loop starts at 0 and misses the last header. This caused problems on OpenBSD since OpenBSD core dumps have the PT_NOTE segment as the last program header.
Reviewers: joerg, labath, krytarowski
Reviewed By: krytarowski
Subscribers: aemerson, emaste, rengolin, srhines, krytarowski, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31131
llvm-svn: 298810
Add missing linkage of the lldbPluginUnwindAssemblyX86 to LLVMMCDisasm
library. This fixes the following build failure when linking against
shared libraries:
lib64/liblldbPluginUnwindAssemblyX86.a(x86AssemblyInspectionEngine.cpp.o):x86AssemblyInspectionEngine.cpp:function lldb_private::x86AssemblyInspectionEngine::instruction_length(unsigned char*, int&): error: undefined reference to 'LLVMDisasmInstruction'
lib64/liblldbPluginUnwindAssemblyX86.a(x86AssemblyInspectionEngine.cpp.o):x86AssemblyInspectionEngine.cpp:function lldb_private::x86AssemblyInspectionEngine::~x86AssemblyInspectionEngine(): error: undefined reference to 'LLVMDisasmDispose'
lib64/liblldbPluginUnwindAssemblyX86.a(x86AssemblyInspectionEngine.cpp.o):x86AssemblyInspectionEngine.cpp:function lldb_private::x86AssemblyInspectionEngine::x86AssemblyInspectionEngine(lldb_private::ArchSpec const&): error: undefined reference to 'LLVMCreateDisasm'
Differential Revision: https://reviews.llvm.org/D31369
llvm-svn: 298777
was formatted into a string inside an assert() expression.
Which is elided when lldb is built with asserts disabled;
the result is that all expressions will fail when debugging
programs using the objective-c v1 runtime.
<rdar://problem/30353271>
llvm-svn: 298694
This #include was the cause of a dependency from Symbol ->
DataFormatters. However, nothing from the header was being
used anyway, so we can just remove it with no adverse effects.
This reduces the overall cycle count from 44 to 43.
llvm-svn: 298541
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:
NetBSD ships with NativeProcessNetBSD inherited from NativeProcessProtocol.
Link Plugins/Process/gdb-remote with lldbPluginProcessNetBSD in order to resolve
correctly the linking to Launch and Attach from the NetBSD plugin.
Sponsored by <The NetBSD Foundation>
Reviewers: kettenis, labath, emaste, joerg
Reviewed By: labath, emaste
Subscribers: mgorny, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31231
llvm-svn: 298524
There are only two users of NativeRegisterContextRegisterInfo,
and both are in process plugins. Moving this code from Host
to Plugins/Process/Utility thus makes sense, and as it is the
only dependency from Host -> PluginProcessUtility, it also
breaks this cycle, reducing LLDB's overall cycle count from
45 to 44.
llvm-svn: 298466
Summary:
NetBSD is a modern ELF UNIX-like system.
There is requires DynamicLoaderPOSIXDYLD e.g. for ELF AUXV reading from the client.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, kettenis
Reviewed By: labath
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31192
llvm-svn: 298409
Summary:
This is the base for introduction of further features to support Process Tracing on NetBSD, in local and remote setup.
This code is also a starting point to synchronize the development with other BSDs. Currently NetBSD is ahead and other systems can catch up.
Sponsored by <The NetBSD Foundation>
Reviewers: emaste, joerg, kettenis, labath
Reviewed By: labath
Subscribers: mgorny, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31138
llvm-svn: 298408
Summary:
NetBSD is an ELF platform and it uses Elf Auxiliary Vector like Linux and other modern BSDs.
While there enable QPassSignals for the NetBSD port as well.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, kettenis, joerg, emaste
Reviewed By: labath
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31146
llvm-svn: 298407
Summary:
NetBSD can share the same logging functionality with Linux and FreeBSD.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, emaste, joerg, kettenis
Reviewed By: labath, emaste
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31191
llvm-svn: 298406
Summary:
NetBSD native threads are printed as 64-bit unsigned integers.
The underlying system type of a thread identity is lwpid_t of type int32_t. For consistency with Linux and FreeBSD share the 64-bit unsigned integer type.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, kettenis, joerg, emaste
Reviewed By: labath, emaste
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31132
llvm-svn: 298405
Summary:
ofstream does not handle paths with non-ascii characters correctly on
windows, so I am switching these to llvm streams to fix that.
Reviewers: zturner, eugene
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31079
llvm-svn: 298375
initialized in the ctor and they're only initialized to 'true' in ClangUserExpression.cpp
when specific languages are detected so we can use uninitialized values. This
bug has been present since the ivars were added in r144042.
<rdar://problem/31105864>
llvm-svn: 298333
This fixes a bug introduced by r291559. The Module's FindType was
passing the original name not the basename in the case where it didn't
find any separators. I also added a testcase for this.
<rdar://problem/31159173>
llvm-svn: 298331
In doing so, clean up the MD5 interface a little. Most
existing users only care about the lower 8 bytes of an MD5,
but for some users that care about the upper and lower,
there wasn't a good interface. Furthermore, consumers
of the MD5 checksum were required to handle endianness
details on their own, so it seems reasonable to abstract
this into a nicer interface that just gives you the right
value.
Differential Revision: https://reviews.llvm.org/D31105
llvm-svn: 298322
Only do this when we are debugging an executable, since we
don't have a good way to trace from an ObjectFile back to its
containing executable. Detecting pre-run libs before running
is "best effort" in lldb, but this one is pretty easy.
llvm-svn: 298290
If you have code before the first line table entry when debugging with .o files on macOS, the
LineTable entry search code was assigning all that code to the first line table entry. Don't do that.
<rdar://problem/31095765>
llvm-svn: 298289
Summary:
GetAuxvData was causing dependencies from host to target and linux
process modules. It also does not fit netbsd use case, as there we can
only read the auxiliary vector with ptrace, which is better done in the
process plugin, with the other ptrace calls.
I resolve these issues by moving the freebsd and linux versions into the
relevant process plugins. In case of linux, this required adding an
interface in NativeProcessProtocol. The empty definitions on other
platforms can simply be removed.
To get the code compiling I had to add ProcessGdbRemote -> ProcessLinux
dependency, which was not caught before because we depended on it
transitively.
Reviewers: zturner, emaste
Subscribers: srhines, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D31031
llvm-svn: 298066
It seems sysctl.h is not self-contained, as I get missing symbols in the
header itself now. I am going to include all files that the file I moved
this from included, and hope that is enough.
llvm-svn: 298063
Summary:
These classes existed only because of the GetName() static function,
which can be moved to a more natural place anyway. I move the linux
version to NativeProcessLinux (and get rid of ProcFileReader), the
freebsd version to ProcessFreeBSD (and fix a bug where it was using the
current process ID, instead of the inferior pid), and remove the NetBSD
version (which was probably incorrect anyway, as it assumes the current
process instead of the inferior.
I also add an llgs test to that verifies thread names are read
correctly.
Reviewers: zturner, krytarowski, emaste
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D30981
llvm-svn: 298058
Previously which path syntax we supported dependend on what
platform we were compiling LLVM on. While this is normally
desirable, there are situations where we need to be able to
handle a path that we know was generated on a remote host.
Remote debugging, for example, or parsing debug info.
99% of the code in LLVM for handling paths was platform
agnostic and literally just a few branches were gated behind
pre-processor checks, so this changes those sites to use
runtime checks instead, and adds a flag to every path
API that allows one to override the host native syntax.
Differential Revision: https://reviews.llvm.org/D30858
llvm-svn: 298004
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:
This fixes the case where a user tries to set a breakpoint on a source
line outside of any function (e.g. because that code is #ifdefed out, or
the compiler did not emit code for the function, etc.) and we would
silently move the breakpoint to the next function.
Now we check whether the line range of the resolved symbol context
function matches the original line number. We reject any breakpoint
locations that appear to move the breakpoint into a new function. This
filtering only happens if we have full debug info available (e.g. in
case of -gline-tables-only compilation, we still set the breakpoint on
the nearest source line).
Reviewers: jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30817
llvm-svn: 297817
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
getpwent is not available on android until API level 21, and even then
it is only available when doing a non-static link. Since android's
concept of users is very different from linux, it's doubtful the home
directory resolution would be useful, so I approximate this state by
just not using getpwent on android.
We've had another getpwent occurance in FileSpec for a while -- it
wasn't causing problems because it was stripped out by the linker, but I
disable that also, for consistency's sake.
llvm-svn: 297612
FileSpec::EnumerateDirectory has a bunch of platform-specific
gunk in it for posix and non-posix platforms. We can get rid
of all this by using LLVM's easy-to-use directory iterators.
Differential Revision: https://reviews.llvm.org/D30807
llvm-svn: 297598
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
about this more I realized I could make the change isolated to
whether we decide an empty accelerator table is valid or not.
<rdar://problem/30867462>
llvm-svn: 297496
HasContent. If we have a valid accelerator table which has no
content, we want to depend on that (empty) table as the authoritative
source instead of reading through all the debug info for lookups.
<rdar://problem/30867462>
llvm-svn: 297441
This is necessary to get debug builds of unit tests working on linux.
I think we are at a point where removing dependencies does not prevent
us from depending on the whole world yet. What it does do though, is
make the dependency chains longer as the dependency graph gets sparser,
which means we need to repeat the libraries more times to get the thing
to link.
llvm-svn: 297369
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
This was originall reverted due to some test failures in
ModuleCache and TestCompDirSymlink. These issues have all
been resolved and the code now passes all tests.
Differential Revision: https://reviews.llvm.org/D30698
llvm-svn: 297300
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 reverts r297116 because it breaks the unittests and
TestCompDirSymlink. The ModuleCache unit test is trivially fixable, but
the CompDirSymlink failure is a symptom of a deeper problem: llvm's stat
functionality is not a drop-in replacement for lldb's. The former is
based on stat(2) (which does symlink resolution), while the latter is
based on lstat(2) (which does not).
This also reverts subsequent build fixes (r297128, r297120, 297117) and
r297119 (Remove FileSpec dependency on FileSystem) which builds on top
of this.
llvm-svn: 297139
This deletes LLDB's FileType enumeration and replaces all
users, and all calls to functions that check whether a file
exists etc with corresponding calls to LLVM.
Differential Revision: https://reviews.llvm.org/D30624
llvm-svn: 297116
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
In an effort to move the various DataBuffer / DataExtractor
classes from Core -> Utility, we have to separate the low-level
functionality from the higher level functionality. Only a
few functions required anything other than reading/writing
raw bytes, so those functions are separated out into a
more appropriate area. Specifically, Dump() and DumpHexBytes()
are moved into free functions in Core/DumpDataExtractor.cpp,
and GetGNUEHPointer is moved into a static function in the
only file that it's referenced from.
Differential Revision: https://reviews.llvm.org/D30560
llvm-svn: 296910
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
Summary:
It does not change members or call non-const members.
HostInfo::GetArchitecture() returns a const object ref (maybe others?),
which can't access the non-const function.
Reviewers: labath, eugene
Reviewed By: labath, eugene
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30515
Author: Jason Majors <jmajors@google.com>
llvm-svn: 296868
This in turn triggered some fallout where other files had
been transitively picking up includes that they needed from
FileSpec.h, so I've fixed those up as well.
llvm-svn: 296855
MSVC (at least the version I am using) does not want to implicitly
capture a const bool variable. Move it into the lambda, as it is not
used outside anyway.
llvm-svn: 296738
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
Summary:
These two register contexts were identical, so this shouldn't cause any
regressions, but I'd appreciate it if you can check that this at least compiles.
Reviewers: emaste, sas
Subscribers: aemerson, rengolin, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27126
llvm-svn: 296335
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
Summary:
There is nothing we can do with the breakpoint once the associated
target becomes deleted. This will make sure we don't hold on to more
resources than we need in this case. In particular, this fixes the case
TestStepOverBreakpoint on windows, where a lingering SBBreakpoint object
causes us to nor unmap the executable file from memory.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30249
llvm-svn: 296328
match but the 'is_regex' argument was not passed as true. Not sure
this is causing a bug, but noticed it while working on another bug.
These formatters gained a regex in r274489 for NDK but didn't pick
up the is_regex flag at the time.
<rdar://problem/30646077>
llvm-svn: 296243
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: QPassSignals package allows lldb client to tell lldb-server to ignore certain types of signals and re-inject them back to inferior without stopping execution.
Reviewers: jmajors, labath
Subscribers: danalbert, srhines, emaste, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30286
Author: Eugene Zemtsov <ezemtsov@google.com>
llvm-svn: 296101
acquired only after checking if the ivar shared pointer was already
filled in. But when I assign an UnwindPlan object to the shared
pointer, I assign an empty object and then fill it in. That leaves
a window where another thread could get the shared pointer to the
empty (but quickly being-filled-in) object and lead to a crash.
Also two changes from Greg for correctness on the TestMultipleDebuggers
test case.
<rdar://problem/30564102>
llvm-svn: 296084
Summary:
NetBSD 7.99.62 introduced Debug Registers interface similar to the FreeBSD one.
This interface will land NetBSD-8.0.
Introduce support for this interface in Register Context NetBSD x86_64 unconditionally as older versions of NetBSD will not be supported.
This change allows to reduce diff with other ports and remove local copy of the RegisterInfos_x86_64.h content.
NetBSD Register Context for 32-bit x86 support will be added later.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, emaste, clayborg
Reviewed By: labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30287
llvm-svn: 296071
Summary:
NetBSD 8.0 will ship with accept4(2) in libc wrapping paccept(2).
This change reduces needless difference with other platforms.
Older versions of NetBSD will not be supported.
No functional change.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, emaste, labath, clayborg
Reviewed By: emaste, labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30288
llvm-svn: 296070
Summary:
This also removes magic rename code, which caused the channel to be
called "linux" when built on a linux machine, and "freebsd" when built
on a freebsd one, which seems unnecessary - registering a new channel is
sufficiently simple now that if we wish to log something extremely
os-specific, we can just create a new channel. None of the current
categories seem very specific to one OS or another.
Reviewers: emaste, krytarowski
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30250
llvm-svn: 295954
Summary:
When lldb-server is started with the -P <port> or -m/-M <min/max port> options to specify which ports are available for remote connections the child debug server is told what port it should listen on. In those cases lldb-server needs to wait for the child to report it’s port number as otherwise it can tell the lldb client that the child is up and listening before it is actually listening on that port. lldb-server already waits in the cases where a port wasn’t specified by waiting until the child reports the port it is using. It was skipping this synchronisation step when passed a port numbers as it knew what the port would be however it does need to ensure the child process has had time to open that port and waiting until the child reports the port number makes sure this has happened.
This patch just removes the one case where a child was spawned and lldb-server did not wait for it to report it’s port number before telling the client lldb process the child is ready to connect to.
This issue was discussed on lldb-dev in a thread here:
http://lists.llvm.org/pipermail/lldb-dev/2017-February/012002.html
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30255
llvm-svn: 295947
- Allow zero byte size request for memory and ensure it gets a unique address
- Exit the free block loop when we find an appropriate free block
<rdar://problem/30644888>
llvm-svn: 295907
Summary:
The main difference here is that in the WINLOG macros you can specify
log categories per call, whereas here you have to go the usual lldb
route of getting a Log* variable first. While this means you have to
write at least two statements, it usually means that each statement will
fit on a single line, whereas fitting the WINLOG invocation on a single
line was almost impossible. So the total size of code does not increase
even in functions with a single log statement, and functions with more
logging get shorter.
The downside here is reduced flexibility in specifying the log
categories, which a couple of functions used quite heavily (e.g.
RefreshStateAfterStop). For these I chose a single category used most
prominently and put everything into that, although a solution with
multiple log variables is definitely possible.
Reviewers: zturner, amccarth
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30172
llvm-svn: 295822
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
Summary:
There have been a few new values added to a few LLVM enums
this change makes sure that LLDB code handles them correctly.
Reviewers: labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30005
Author: Eugene Zemtsov <ezemtsov@google.com>
llvm-svn: 295445
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
In the case we are stepping over the thread creation instruction, we
will end up calling Thread::SingleStep back-to-back twice (because of
the intermediate PTRACE_EVENT_CLONE stop). This will cause the cpu mask
to be set inappropriately (because the old SingleStepCheck object will
be destroyed after we create the new one), and the single-step will
fail.
Before the refactor the code was still incorrect in this case, but in a
different way (the thread was left with the incorrect mask after the
stepping was complete), so this was not easy to spot.
This fixes TestCreateDuringInstructionStep on the affected devices.
llvm-svn: 295440
While refactoring the code in r293046 I made a very basic error -
relying on destructor side-effects of a copyable object. Fix that and
make the object non-copyable.
This fixes the tests on the platforms that need this workaround, but
unfortunately we don't have a way to make a more platform-agnostic test
right now.
llvm-svn: 295345
TSan now has the ability to report races on "external" object, i.e. any library class/object that has read-shared write-exclusive threading semantics. The detection and reporting work almost out of the box, but TSan can now provide the type of the object (as a string). This patch implements this into LLDB.
Differential Revision: https://reviews.llvm.org/D30024
llvm-svn: 295342
effects was passed as an expression to assert() calls. If lldb is
built without asserts, the expression was eliminated and we lost
the side effects -- these methods stopped working.
<rdar://problem/30342959>
llvm-svn: 295271
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
Summary:
It turns out listing each library twice is not enough to resolve all
references in a debug build on linux - a number of executables fails to
link with random symbols missing. Increasing the number to three seems
to be enough. The choice of lldbCore to set the multiplicity on is
somewhat arbitrary, but it seems fitting, as it is the biggest layering
transgressor.
Reviewers: beanz
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D29888
llvm-svn: 295189
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
Summary:
We've had two ways to print a "debug" log message.
- Log::GetDebug() was testing a Stream flag which was never set.
- Log::Debug() was checking for the presence of "log enable --debug"
flag.
Given that these two were used very rarely and we already have a
different way to specify "I want a more verbose log", I propose to remove
these two functions and migrate the callers to LLDB_LOGV. This commit
does that.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D29823
llvm-svn: 294939
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
After many expressions are evaluated we were spending time looking for open blocks on memory in the one or more AllocatedBlock objects and it would slow down expression evaluation.
I implemented a fixed size blocks implementation that maintains a sorted free list to fix the issue.
<rdar://problem/17962974>
llvm-svn: 294600
CommandObjectVersion.cpp calls lldb_private::GetVersion (present in lldbBase).
This should fix the unittest link on windows. I am not sure why is this not
present on other platforms -- my guess is that there lldbBase is included in
the link through some other dependency chain.
llvm-svn: 294549
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
Inspired by r294145 for NetBSD, this reduces diffs between the FreeBSD
and Linux/NetBSD Platform implementations. Further diff reduction will
occur once FreeBSD switches to using the remote process plugin.
Differential Revision: https://reviews.llvm.org/D29667
llvm-svn: 294340
Instead just rely on LLDB_LOG().
This is part of an effort to sort out dependency hell in LLDB.
Error is in Utility, but Log is in Core. Core can depend on
Utility, but not vice versa. So this patch moves the knowledge
about how to log Errors from the Error class to the Log file.
Differential Revision: https://reviews.llvm.org/D29514
llvm-svn: 294210
Summary:
The std::call_once implementation in libstdc++ has problems on few systems: NetBSD, OpenBSD and Linux PPC. LLVM ships with a homegrown implementation llvm::call_once to help on these platforms.
This change is required in the NetBSD LLDB port. std::call_once with libstdc++ results with crashing the debugger.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, emaste, mehdi_amini, clayborg
Reviewed By: labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29288
llvm-svn: 294202
Summary:
Update the code to the new world code.
These changes are needed for remote process plugin.
Sponsored by <The NetBSD Foundation>
Reviewers: emaste, clayborg, joerg, labath
Reviewed By: clayborg, labath
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29266
llvm-svn: 294145
don't create a platform.linux setting category, as it contains no
actual settings, and I don't forsee adding any soon. Also remove some
unused includes while I'm in there.
llvm-svn: 294114
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
Summary:
- GetFileWithUUID: All platforms except PlatformDarwin had this.
However, I see no reason why this code would not apply there as well.
- GetProcessInfo, FindProcesses: The implementation was the same in all classes.
- GetFullNameForDylib: This code should apply to all non-darwin
platforms. I've kept the PlatformDarwin override as the situation is
different there.
Reviewers: clayborg, krytarowski, emaste
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D29496
llvm-svn: 294019
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
Summary:
various platforms very using nearly identical code for this method. As far as I
can tell there was nothing platform-specific about the differences, but rather
it looked like it was caused by tiny tweaks being made to individual copies
without affecting the overall functionality. I have taken the superset of all
these tweaks and put it into one method in the base class (incidentaly, nobody
was using the base class implementation of the method, as all classes were
overriding it). From the darwin class I took the slightly improved error
reporting (checking whether the file is readable) and the
ResolveExecutableInBundle call (which has no effect elsewhere as the function
is already a no-op on non-darwin platforms). From the linux class I took the
set-the-triple-vendor-to-host-if-unspecified tweak (present in PlatformKalimba
as well).
PlatformWindows has an identical copy as well. We could resolve that by pushing
this code further down into Platform class, that that would require pushing the
m_remote_platform_sp member as well, which seems like a bad design choice.
Reviewers: clayborg, emaste, krytarowski
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D29406
llvm-svn: 293910
print the path being requested.
Change the GetInfoItemByPathAsString docuemtnation in
the .i file to use docstring instead of autodoc so
the function signature is included in the python
help.
<rdar://problem/29999567>
llvm-svn: 293858
Chris Bieneman