| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 298399
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This removes the last usage of ProcFileReader from NativeProcessLinux
and then deletes the class itself.
llvm-svn: 298374
|
|
|
|
|
|
|
| |
Hopefully this works, I can't test since I don't have Mac
hardware, however.
llvm-svn: 298340
|
|
|
|
|
|
| |
on macosx.
llvm-svn: 298338
|
|
|
|
|
|
|
| |
can dereference misaligned memory.
<rdar://problem/31106315>, <rdar://problem/31106337>
llvm-svn: 298337
|
|
|
|
| |
llvm-svn: 298335
|
|
|
|
|
|
|
|
| |
Use LLVM's equivalent versions instead.
Differential Revision: https://reviews.llvm.org/D31111
llvm-svn: 298334
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D31110
llvm-svn: 298326
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D31108
llvm-svn: 298325
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
table entries.
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
|
|
|
|
| |
llvm-svn: 298206
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D31089
llvm-svn: 298205
|
|
|
|
|
|
|
|
| |
Have callers use llvm::sys::fs::create_directory() instead.
Differential Revision: https://reviews.llvm.org/D31086
llvm-svn: 298203
|
|
|
|
| |
llvm-svn: 298189
|
|
|
|
|
|
|
| |
Patch by Hugh Bellamy
Differential Revision: https://reviews.llvm.org/D30926
llvm-svn: 298099
|
|
|
|
| |
llvm-svn: 298069
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
broken by r298058.
llvm-svn: 298061
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 298011
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 297819
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function boundaries
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
|
|
|
|
| |
llvm-svn: 297640
|
|
|
|
| |
llvm-svn: 297637
|
|
|
|
|
|
|
|
| |
Also has the side-effect of fixing the build on systems with glibc < 2.12
https://reviews.llvm.org/D30844
llvm-svn: 297626
|
|
|
|
|
|
| |
I have got my boolean logic incorrect. Sorry about the spam.
llvm-svn: 297615
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Propagate changes that were made during review, and fix a couple of
warnings while I'm in there.
llvm-svn: 297609
|
|
|
|
|
|
|
|
|
|
| |
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 fixes the compilation failures with the original patch.
llvm-svn: 297597
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
LLVM now has such a function, so we use that instead.
llvm-svn: 297360
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
actions
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
|
|
|
|
| |
llvm-svn: 297128
|