The intention in r355323 has been to implement a no-op resolver in the
HostInfoBase class, which will then be shadowed a an implementation in
the HostInfoPosix class. However, I add the shadowing declaration in
HostInfoPosix.h, and instead had implemented the HostInfoBase function
in HostInfoPosix.cpp. This has lead to undefined symbols on windows, and
a subsequent implementation of a no-op resolver in HostInfoWindows
(r355329).
Since now there is no point on having a no-op resolver in the base
class, I just remove the base declaration altogether, and have
HostInfoPosix implement the (newly-declared) HostInfoPosix version of
that function.
llvm-svn: 355398
There are set of classes in Target that describe the parameters of a
process - e.g. it's PID, name, user id, and similar. However, since it
is a bare description of a process and contains no actual functionality,
there's nothing specifically that makes this appropriate for being in
Target -- it could just as well be describing a process on the host, or
some hypothetical virtual process that doesn't even exist.
To cement this, I'm moving these classes to Utility. It's possible that
we can find a better place for it in the future, but as it is neither
Host specific nor Target specific, Utility seems like the most appropriate
place for the time being.
After this there is only 2 remaining references to Target from Host,
which I'll address in a followup.
Differential Revision: https://reviews.llvm.org/D58842
llvm-svn: 355342
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
That patch added a function to HostInfo that returns an instance
of UserIDResolver, but this function was unimplemented on Windows,
leading to linker errors. For now, just return a dummy implementation
that doesn't resolve user ids to get the build green.
llvm-svn: 355329
Summary:
This creates an abstract base class called "UserIDResolver", which can
be implemented to provide user/group ID resolution capabilities for
various objects. Posix host implement a PosixUserIDResolver, which does
that using posix apis (getpwuid and friends). PlatformGDBRemote
forwards queries over the gdb-remote link, etc. ProcessInstanceInfo
class is refactored to make use of this interface instead of taking a
platform pointer as an argument. The base resolver class already
implements caching and thread-safety, so implementations don't have to
worry about that.
The main motivating factor for this was to remove external dependencies
from the ProcessInstanceInfo class (so it can be put next to
ProcessLaunchInfo and friends), but it has other benefits too:
- ability to test the user name caching code
- ability to test ProcessInstanceInfo dumping code
- consistent interface for user/group resolution between Platform and
Host classes.
Reviewers: zturner, clayborg, jingham
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D58167
llvm-svn: 355323
Use '127.0.0.1' instead of 'localhost' in ConnectLocally() function
as this is the specific address the server is bound to. Using
'localhost' may involve trying IPv6 first which may accidentally be used
by another service.
While technically it might be interesting to support IPv6 here, it would
need to be supported properly, with the connection copying family
and address from the listening socket, and possibly without relying
on existence of 'localhost' at all.
Differential Revision: https://reviews.llvm.org/D58883
llvm-svn: 355285
automatic move should not fire when returning type T in a function with
result type Expected<T>. Some compilers seem to allow that nonetheless.
llvm-svn: 355270
This patch adds the necessary logic to capture and replay commands
entered into the command interpreter. A DataRecorder shadows the input
and writes its data to a know file. During replay this file is used as
the command interpreter's input.
It's possible to the command interpreter more than once, with a
different input source. We support this scenario by using multiple
buffers. The synchronization for this takes place at the SB layer, where
we create a new recorder every time the debugger input is changed.
During replay we use the corresponding buffer as input.
Differential revision: https://reviews.llvm.org/D58564
llvm-svn: 355249
When the debugger is run in sync mode, you need to
be able to tell whether a hijacked resume is for some
special purpose (like waiting for the SIGSTOP on attach)
or just to perform a synchronous resume. Target::Launch was doing
that wrong, and that caused stop-hooks on process launch
in source files to behave incorrectly.
<rdar://problem/48115661>
Differential Revision: https://reviews.llvm.org/D58727
llvm-svn: 355213
from 30 seconds to 120 seconds. We've seen cases where
this symbol lookup can exceed 30 seconds for people
working remotely.
<rdar://problem/48460476>
llvm-svn: 355169
Summary:
The clang headers are useful when dealing with clang modules. There is also a
way to get to the clang headers from the SB API so it would be nice if they were
also available when we just build lldb.
Differential Revision: https://reviews.llvm.org/D58793
llvm-svn: 355149
The existing comment about over-allocating the command line was incorrect. The
contents of the command line may be changed, but it's not necessary to over
allocate. The changes will be limited to the existing contents of the string
(e.g., by replacing spaces with L'\0' to tokenize the command line).
Also added a comment explaining a possible cause of failure to save the next
programmer some time when they try to debug a 64-bit process from a 32-bit
LLDB.
llvm-svn: 355121
This extra call to the demangler doesn't affect the performance of C++
because the result is being cached anyway; but I'm working on a patch
to the Swift branch that uses extra contextual information to provide
a more accurate demangling result. In that case this call would be
extra and unnecessary work.
Differential Revision: https://reviews.llvm.org/D58720
llvm-svn: 355042
Given that we have a target named Symbols, one wonders why a
file named Symbols.cpp is not in this target. To be clear,
the functions exposed from this file are really focused on
*locating* a symbol file on a given host, which is where the
ambiguity comes in. However, it makes more sense conceptually
to be in the Symbols target. While some of the specific places
to search for symbol files might change depending on the Host,
this is not inherently true in the same way that, for example,
"accessing the file system" or "starting threads" is
fundamentally dependent on the Host.
PDBs, for example, recently became a reality on non-Windows platforms,
and it's theoretically possible that DSYMs could become a thing on non
MacOSX platforms (maybe in a remote debugging scenario). Other types of
symbol files, such as DWO, DWP, etc have never been tied to any Host
platform anyway.
After this patch, there is only one remaining dependency from
Host to Target.
Differential Revision: https://reviews.llvm.org/D58730
llvm-svn: 355032
Traditionally objc had two entry points, objc_msgSend for scalar
return methods, and objc_msgSend_stret for struct return convention
methods. But on arm64 the second was not needed (since arm64 doesn't
use an argument register for the struct return pointer) so it was removed.
The code that dispatches to the objc object checker when it sees some
flavor of objc_msgSend was not aware of this change so was sending the
wrong arguments to the checker.
<rdar://problem/48315890>
Differential Revision: https://reviews.llvm.org/D58699
llvm-svn: 355026
Debugging issues with instrumentation capture and replay can be
particularly tricky, especially because part of the process takes places
even before the debugger is initialized. This patch adds more logging
capabilities to these classes, hidden behind a macro define.
Differential revision: https://reviews.llvm.org/D58566
llvm-svn: 355002
Summary:
This behavior was originally added in rL252264 (git commit 76a7f365da)
in order to be extra careful with handling platforms like watchos and tvos.
However, as far as triples go, those two (and others) are treated as OSes and
not environments, so that should not really apply here.
Additionally, this behavior is incorrect and can lead to incorrect ArchSpecs.
Because android is specified as an environment and not an OS, not propogating
the environment can lead to modules and targets being misidentified.
Differential Revision: https://reviews.llvm.org/D58664
llvm-svn: 354938
Summary:
These functions should always return the opposite of the
`Triple{Environment,OS,Vendor}WasSpecified` functions. Unspecified unknown is
the same as unspecified, which is why one set of functions should give us what
we want. It's possible to have specified unknown, which is why we can't just
rely on checking the enum values of vendor/os/environment. We must also ensure
that the names of these are empty and not "unknown".
Differential Revision: https://reviews.llvm.org/D58653
llvm-svn: 354933
They aren't designed to nest recursively, so this will prevent that.
Also add a --auto-continue flag, putting "continue" in the stop hook makes
the stop hooks fight one another in multi-threaded programs.
Also allow more than one -o options so you can make more complex stop hooks w/o
having to go into the editor.
<rdar://problem/48115661>
Differential Revision: https://reviews.llvm.org/D58394
llvm-svn: 354706
The deserializer was not handling this case. For now we just
accept the absent option, and set it to the breakpoint default.
This will be more important if/when I figure out how to serialize
the options set on breakpont locations.
<rdar://problem/48322664>
llvm-svn: 354702
remove the Initialize function, move the things that can fail into the
static factory function. The factory function now returns
Expected<Parser> instead of Optional<Parser> so that it can give a
reason why creation failed.
llvm-svn: 354668
As per the discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20190218/048007.html
This commit implements option (3):
> Go back to initializing the reproducer before the rest of the debugger.
> The method wouldn't be instrumented and guarantee no other SB methods are
> called or SB objects are constructed. The initialization then becomes part
> of the replay.
Differential revision: https://reviews.llvm.org/D58410
llvm-svn: 354631
Summary:
While debugging an android process remotely from a windows machine, I
noticed that the modules constructed from an object file in memory only had
information about the architecture. Without knowledge of the OS or environment,
expression evaluation sometimes leads to incorrectly generated code or a
debugger crash. While we cannot know for certain what triple a module
constructed from an in-memory object file will have, we can use the
triple from the target to try and fill in the missing details.
Reviewers: clayborg, zturner, JDevlieghere, compnerd, aprantl, labath
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58405
llvm-svn: 354526
Split the recognition into NetBSD executables & shared libraries
and core(5) files.
Introduce new owner type: "NetBSD-CORE", as core(5) files are not tagged
in the same way as regular NetBSD executables.
Stop using incorrectly ABI_TAG and ABI_SIZE. Introduce IDENT_TAG,
IDENT_DECSZ, IDENT_NAMESZ and PROCINFO.
The new values detect correctly the NetBSD images.
The patch has been originally written by Kamil Rytarowski. I've added
tests and applied minor code changes per review. The work has been
sponsored by the NetBSD Foundation.
Differential Revision: https://reviews.llvm.org/D42870
llvm-svn: 354466
Facebook creates minidump files that contain specific information about why things crash. Adding ways to dump these allows tools to be made that can auto download symbols based on the information that is contained in the minidump files.
Differential Revision: https://reviews.llvm.org/D58398
llvm-svn: 354385
This reverts r354263, because it uncovered a problem in handling of the
minidumps with conflicting UUIDs. If a minidump contains two files with
the same UUID, we will not create to placeholder modules for them, but
instead reuse the first one for the second instance. This creates a
problem because these modules have their load address hardcoded in them
(and I've added an assert to verify that).
Technically this is not a problem with this patch, as the same issue
existed in the previous implementation, but it did not have the assert
which would diagnose that. Nonetheless, I am reverting this until I
figure out what's the best course of action in this situation.
llvm-svn: 354324
instead of printf-ing into a buffer, and them using that buffer as a
format string, simply use the appropriate indirect format string.
This also fixes a -Wformat-truncation warning with gcc.
llvm-svn: 354307
In r353906 we hooked up clang and lldb's reproducer infrastructure to
capture files used by clang. This patch adds the necessary logic to have
clang reuse the files from lldb's reproducer during replay.
Differential revision: https://reviews.llvm.org/D58309
llvm-svn: 354283
This re-commits r353677, which was reverted due to test failures on the
windows bot. The issue there was that ObjectFilePECOFF vended its base
address through the incorrect interface. SymbolFilePDB depended on that,
which lead to assertion failures when SymbolFilePDB was attempting to
use the placeholder object files as a base. This has been fixed in
r354258
It also fixes one small problem in the original patch. The issue was that the
Module class would attempt to overwrite the object file we created in
CreateModuleFromObjectFile if the file corresponding to the placeholder object
file happened to exist (but we have already disqualified it due to UUID
mismatch. The fix is simple -- we set the m_did_load_objfile flag to properly
record the fact that we have already created an object file for the module.
The original commit message was:
The reason this wasn't working was that ProcessMinidump was creating odd
object-file-less modules, and SymbolFileBreakpad required the module to
have an associated object file because it needed to get its base
address.
This fixes that by introducing a PlaceholderObjectFile to serve as a
dummy object file. The general idea for this is taken from D55142, but
I've reworked it a bit to avoid the need for the PlaceholderModule
class. Now that we have an object file, our modules are sufficiently
similar to regular modules that we can use the regular Module class
almost out of the box -- the only thing I needed to tweak was the
Module::CreateModuleFromObjectFile functon to set the module's FileSpec
in addition to it's architecture. This wasn't needed for ObjectFileJIT
(the other user of CreateModuleFromObjectFile), but it shouldn't hurt it
either, and the change seems like a straightforward extension of this
function.
Reviewers: clayborg, lemo, amccarth
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D57751
llvm-svn: 354263
COFF files are modelled in lldb as having one big container section
spanning the entire module image, with the actual sections being
subsections of that. In this model, the base address is simply the
address of the first byte of that section.
This also removes the hack where ObjectFilePECOFF was using the
m_file_offset field to communicate this information. Using file offset
for this purpose is completely wrong, as that is supposed to indicate
where is this ObjectFile located in the file on disk. This field is only
meaningful for fat binaries, and should normally be 0.
Both PDB plugins have been updated to use GetBaseAddress instead of
GetFileOffset.
llvm-svn: 354258
class template back to the template.
Previously, when the ASTImporter imported the class, it didn't know that
it was the pattern of a class template, so made the class a name lookup
result for the name of the template, resulting in ambiguity errors when
naming the template.
Due to a clang bug (fixed in r354091, reverted and soon to be
re-committed), ambiguity errors between a template and a non-template
were previously not diagnosed. Once r354091 is re-committed, this will
be covered by existing lldb tests.
llvm-svn: 354173
Summary:
This commit modifies the OnLoadModule method to resolve the module
unless we already have one
Change by Hui Huang to fix the failing LLDB tests on Windows
Reviewers: labath, asmith
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D58303
llvm-svn: 354172
Host had a function to get the UnixSignals instance corresponding
to the current host architecture. This means that Host had to
include a file from Target. To break this dependency, just make
this a static function directly in UnixSignals. We already have
the function UnixSignals::Create(ArchSpec) anyway, so we just
need to have UnixSignals::CreateForHost() which determines which
value to pass for the ArchSpec.
The goal here is to eventually break the Host->Target->Host
circular dependency.
Differential Revision: https://reviews.llvm.org/D57780
llvm-svn: 354168
Summary: As seen in a crash report, the C-string returned for the directory component of `target_file` can null. It should not be assigned to `std::string` directly as this is undefined behavior.
Reviewers: jingham
Reviewed By: jingham
Subscribers: jdoerfert, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D57964
llvm-svn: 354145
I reduced the alignment of this struct in r342029 to avoid compiler
warnings about under-aligned allocations, but it turns out that this
still causes problems with some compilers (see r353778). As I hinted in
r342029, I don't believe any special aligment is necessary here (the
only reason for that would be if we used some aligned SSE instructions to
access this buffer, but I don't see any reason why we should do that),
so here I go all the way, and remove the alignment requirements (except
the ones naturally imposed by basic types) altogether.
llvm-svn: 354125
Add missing EINTR handling for kevent() calls. If the call is
interrupted, return from Poll() as if zero events were returned and let
the polling resume on next iteration. This fixes test flakiness
on NetBSD.
Includes a test case suggested by Pavel Labath on D42206.
Differential Revision: https://reviews.llvm.org/D58230
llvm-svn: 354122
Summary:
When a process is loaded, update its sections with the load address to resolve any created breakpoints. For the remote debugging case, the debugged process is launched remotely so GetLoadAddress is intended to pass the load address from remote to LLDB (client).
Reviewers: zturner, llvm-commits, clayborg, labath
Reviewed By: labath
Subscribers: mgorny, sas, Hui, clayborg, labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D56237
llvm-svn: 354099
Remove the redundant termination clause from within the loop. Since
the check is done at the end of the loop, it's entirely redundant
to the 'while' condition. If termination was requested, the latter
will become false and the 'while' loop will terminate, resulting
in the 'return' statement below the loop being executed (which is
equivalent to the one used inside 'if').
Differential Revision: https://reviews.llvm.org/D58227
llvm-svn: 354050
I was looking at the ClangExpressionParser and noticed that we have a
FileManager owned by the expression parser and later ask the compiler
instance to create a new FileManager, owned by the clang CI. Looking at
the code I don't see a good reason for having two instances. This patch
removes the one owned by LLDB.
Differential revision: https://reviews.llvm.org/D58222
llvm-svn: 354041
Summary:
This is a preparatory step to enable adding extra unwind strategies by
symbol file plugins. This has been discussed on the lldb-dev mailing
list: <http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>.
Reviewers: jasonmolenda, clayborg, espindola
Subscribers: lemo, emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D58129
llvm-svn: 354033
Modify the kevent() error reporting to use errno rather than returning
the return value. At least on FreeBSD and NetBSD, kevent() always
returns -1 in case of error, and the actual error is returned via errno.
Differential Revision: https://reviews.llvm.org/D58229
llvm-svn: 354029
Summary:
Implement a few routines for Windows to support some basic process interaction and file system operations.
Reviewers: zturner, llvm-commits, labath, jingham
Reviewed By: labath
Subscribers: emaste, jdoerfert, Hui, labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D56232
llvm-svn: 354010
This patch properly extracts the full submodule path as well as its
search paths from DWARF import decls and passes it on to the
ClangModulesDeclVendor.
rdar://problem/47970144
Differential Revision: https://reviews.llvm.org/D58090
llvm-svn: 353961
Summary:
This is coming from the discussion in D55356 (the most interesting part
happened on the mailing list, so it isn't reflected on the review page).
In short the issue is that lldb assumes that all bytes of a module image
in memory will be backed by a "section". This isn't the case for PECOFF
files because the initial bytes of the module image will contain the
file header, which does not correspond to any normal section in the
file. In particular, this means it is not possible to implement
GetBaseAddress function for PECOFF files, because that's supposed point
to the first byte of that header.
If my (limited) understanding of how PECOFF files work is correct, then
the OS is expecded to load the entire module into one continuous chunk
of memory. The address of that chunk (+/- ASLR) is given by the "image
base" field in the COFF header, and it's size by "image size". All of
the COFF sections are then loaded into this range.
If that's true, then we can model this behavior in lldb by creating a
"container" section to represent the entire module image, and then place
other sections inside that. This would make be consistent with how MachO
and ELF files are modelled (except that those can have multiple
top-level containers as they can be loaded into multiple discontinuous
chunks of memory).
This change required a small number of fixups in the PDB plugins, which
assumed a certain order of sections within the object file (which
obivously changes now). I fix this by changing the lookup code to use
section IDs (which are unchanged) instead of indexes. This has the nice
benefit of removing spurious -1s in the plugins as the section IDs in
the pdbs match the 1-based section IDs in the COFF plugin.
Besides making the implementation of GetBaseAddress possible, this also
improves the lookup of addresses in the gaps between the object file
sections, which will now be correctly resolved as belonging to the
object file.
Reviewers: zturner, amccarth, stella.stamenova, clayborg, lemo
Reviewed By: clayborg, lemo
Subscribers: JDevlieghere, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D56537
llvm-svn: 353916
The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.
In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.
I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.
llvm-svn: 353912
This patch hooks up clang and lldb's reproducers functionality. It
ensures that when capturing a reproducer, headers and modules imported
through the expression parser are collected.
Differential revision: https://reviews.llvm.org/D58076
llvm-svn: 353906
This enables the function to be called with a StringRef without jumping
through any hoops. I rename the function to "PutStringAsRawHex8" to
honor the extended interface. I also remove ".c_str()" from any calls to
this function I could find.
llvm-svn: 353841
Summary:
The two classes contained a lot of duplicated code, but there wasn't a
good place to factor it to. It couldn't be the base Platform class,
since we also have platforms which are only remote (such as
PlatformGDBRemoteServer), and so it did not make sense for those to have
an m_remote_platform member.
This patch creates a new class, RemoteAwarePlatform, which can serve as
a base class for platforms which can both serve as a host, and forward
actions to a remote system. It is motivated partly by D56232 (which was
about to add a bunch of additional duplicated methods), and partly by my
own need to modify a function which happens to be implemented in both
places identically.
The patch moves the methods which are trivially identical in the two
classes into the common base class, there were one or two more methods
which could probably be merged into one, but this wasn't completely
trivial, so I did not attempt to do that now.
Reviewers: jingham, zturner, clayborg, asmith
Subscribers: emaste, mgorny, Hui, lldb-commits
Differential Revision: https://reviews.llvm.org/D58052
llvm-svn: 353812
Summary:
This patch makes virtual bases to be added in the correct order to the bases
list. It is important because `VTableContext` (`MicrosoftVTableContext` in our
case) uses then the order of virtual bases in the list to restore the virtual
table indexes. These indexes are used then to resolve the layout of the virtual
bases.
We haven't enough information about offsets of virtual bases regarding to the
object (moreover, in a common case we can't rely on such information, see the
example here: https://reviews.llvm.org/D53506#1272306 ), but there should be
enough information to restore the layout of the virtual bases from the indexes
in runtime. After D53506 this information is used whenever possible, so there
should be no problems with virtual bases' fields reading.
Reviewers: zturner, rnk, stella.stamenova
Subscribers: abidh, teemperor, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D56904
llvm-svn: 353806
Apparently there are multiple places where MSVC complains about
instantiations with extended aligment. I think it's better to define
`_ENABLE_EXTENDED_ALIGNED_STORAGE` as suggested by the error message.
I don't have access to a Windows machine so this is all speculative.
llvm-svn: 353778
Unlike std::make_unique, which is only available since C++14,
std::make_shared is available since C++11. Not only is std::make_shared
a lot more readable compared to ::reset(new), it also performs a single
heap allocation for the object and control block.
Differential revision: https://reviews.llvm.org/D57990
llvm-svn: 353764
instead of returning the UUID through by-ref argument and a boolean
value indicating success, we can just return it directly. Since the UUID
class already has an invalid state, it can be used to denote the failure
without the additional bool.
llvm-svn: 353714
Summary:
This adds support for auto-detection of path style to SymbolFileBreakpad
(similar to how r351328 did the same for DWARF). We guess each file
entry separately, as we have no idea which file came from which compile
units (and different compile units can have different path styles). The
breakpad generates should have already converted the paths to absolute
ones, so this guess should be reasonable accurate, but as always with
these kinds of things, it is hard to give guarantees about anything.
In an attempt to bring some unity to the path guessing logic, I move the
guessing logic from inside SymbolFileDWARF into the FileSpec class and
have both symbol files use it to implent their desired behavior.
Reviewers: clayborg, lemo, JDevlieghere
Subscribers: aprantl, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D57895
llvm-svn: 353702
Summary:
The reason this wasn't working was that ProcessMinidump was creating odd
object-file-less modules, and SymbolFileBreakpad required the module to
have an associated object file because it needed to get its base
address.
This fixes that by introducing a PlaceholderObjectFile to serve as a
dummy object file. The general idea for this is taken from D55142, but
I've reworked it a bit to avoid the need for the PlaceholderModule
class. Now that we have an object file, our modules are sufficiently
similar to regular modules that we can use the regular Module class
almost out of the box -- the only thing I needed to tweak was the
Module::CreateModuleFromObjectFile functon to set the module's FileSpec
in addition to it's architecture. This wasn't needed for ObjectFileJIT
(the other user of CreateModuleFromObjectFile), but it shouldn't hurt it
either, and the change seems like a straightforward extension of this
function.
Reviewers: clayborg, lemo, amccarth
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D57751
llvm-svn: 353677
Fix MainLoop::RunImpl::get_sigmask() to correctly return empty sigset_t
when SIGNAL_POLLING_UNSUPPORTED is true. On NetBSD (and probably
on some other platforms), integers are not implicitly convertible to
sigset_t, so 'return 0' is erraneous. Instead, sigset_t should be reset
through sigemptyset().
While at it, move common parts out of the #ifdef.
Differential Revision: https://reviews.llvm.org/D57959
llvm-svn: 353675
Summary: Replace 0xc9 (LEAVE) with 0xcb (RETF) in ret_pattern_p(). Also put 0xc3 first, since it is the most common form and will match first.
Reviewers: jasonmolenda
Reviewed By: jasonmolenda
Subscribers: labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D57928
llvm-svn: 353643
Summary: Update the OpenBSD Host.cpp for the new SetFile() function signature. Fixes compiling lldb on OpenBSD.
Reviewers: krytarowski
Reviewed By: krytarowski
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D57907
llvm-svn: 353642
Summary:
This commit contains the following changes:
- Rewrite vfile close/read/write packet handlers with portable routines from lldb.
This removes #if(s) and allows the handlers to work on Windows.
- Fix a bug in File::Write. This is intended to write data at an offset to a file
but actually writes at the current position of the file.
- Add a default boolean argument 'should_close_fd' to FileSystem::Open to
let the user decide whether to close the fd or not.
Reviewers: zturner, llvm-commits, labath
Reviewed By: zturner
Subscribers: Hui, labath, abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D56231
llvm-svn: 353446
The "signal" argument was removed from the MonitorCallback function, but
not from the log statements within it. This wasn't noticed because the
name "signal" suddenly started referring to the libc function with that
name.
This fixes that.
llvm-svn: 353419
GetIndexForObjectImpl generated a bunch of "conversion casts away
constness warnings". Change the function to use "const void *" (and
static_cast, while I'm at it), to avoid this.
Driver.cpp: unused variable "replay" (this was actually caused by a
subsequent partial revert of this patch). I just finish the revert by
removing the variable completely.
llvm-svn: 353405
Summary:
This patch teaches SymbolFileBreakpad to parse the line information in
breakpad files and present it to lldb.
The trickiest question here was what kind of "compile units" to present
to lldb, as there really isn't enough information in breakpad files to
correctly reconstruct those.
A couple of options were considered
- have the entire file be one compile unit
- have one compile unit for each FILE record
- have one compile unit for each FUNC record
The main drawback of the first approach is that all of the files would
be considered "headers" by lldb, and so they wouldn't be searched if
target.inline-breakpoint-strategy=never. The single compile unit would
also be huge, and there isn't a good way to name it.
The second approach will create mostly correct compile units for cpp
files, but it will still be wrong for headers. However, the biggest
drawback here seemed to be the fact that this can cause a compile unit
to change mid-function (for example when a function from another file is
inlined or another file is #included into a function). While I don't
know of any specific thing that would break in this case, it does sound
like a thing that we should avoid.
In the end, we chose the third option, as it didn't seem to have any
major disadvantages, though it was not ideal either. One disadvantage
here is that this generates a large number of compile units, and there
is still a question on how to name it. We chose to simply name it after
the first line record in that function. This should be correct 99.99% of
the time, though it can produce somewhat strange results if the very
first line record comes from an #included file.
Reviewers: clayborg, zturner, lemo, markmentovai
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56595
llvm-svn: 353404
instructions
Summary: This patch makes `x86AssemblyInspectionEngine` to process zero value of
the `B` field of the `REX` prefix in a correct way for `PUSH` and `POP`
instructions. MSVC sometimes emits `pushq %rbp` instruction as `0x40 0x55`, and
it was not parsed correctly before.
Reviewers: jasonmolenda, labath
Reviewed By: jasonmolenda, labath
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D57745
llvm-svn: 353281
LLDB testsuite fails when built by GCC8 on:
LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp
This is because this code in LLDB codebase has undefined behavior:
#include <algorithm>
#include <string.h>
// lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:1731
static struct section_64 {
char sectname[16];
char segname[16];
} sect64 = { {'_','_','a','p','p','l','e','_','n','a','m','e','s','p','a','c'}, "__DWARF" };
int main() {
return std::min<size_t>(strlen(sect64.sectname), sizeof(sect64.sectname));
}
It has been discussed as a (false) bugreport to GCC:
wrong-code: LLDB testcase fails: SymbolFile/DWARF/find-basic-namespace.cpp
https://bugzilla.redhat.com/show_bug.cgi?id=1672436
Differential Revision: https://reviews.llvm.org/D57781
llvm-svn: 353280
Previously, there were two different scripts for generating VCS headers:
one used by LLVM and one used by Clang and lldb. They were both similar,
but different. They were both broken in their own ways, for example the
one used by Clang didn't properly handle monorepo resulting in an
incorrect version information reported by Clang.
This change unifies two the scripts by introducing a new script that's
used from both LLVM, Clang and lldb, ensures that the new script
supports both monorepo and standalone SVN and Git setups, and removes
the old scripts.
Differential Revision: https://reviews.llvm.org/D57063
llvm-svn: 353268
An equivalent change was made to RemapPaths, but it needed to be made
here as well. Also added a test for this and made the setup a little
more complex to avoid false successes.
<rdar://problem/47642498>
Differential Revision: https://reviews.llvm.org/D57552
llvm-svn: 353243
Type punning through a union -> no good.
double to uint64 to double again -> no good either.
The nice side effect, other than silencing the sanitizer bot
is that it fixes the formatting of some dates, e.g. Jan 1st 1970.
<rdar://problem/47617983>
llvm-svn: 353191
Summary:
This patch adds support of expression evaluation in a context of some object.
Consider the following example:
```
struct S {
int a = 11;
int b = 12;
};
int main() {
S s;
int a = 1;
int b = 2;
// We have stopped here
return 0;
}
```
This patch allows to do something like that:
```
lldb.frame.FindVariable("s").EvaluateExpression("a + b")
```
and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be
used (not locals `a` and `b`).
This is achieved by replacing of `this` type and object for the expression. This
has some limitations: an expression can be evaluated only for values located in
the debuggee process memory (they must have an address of `eAddressTypeLoad`
type).
Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille
Reviewed By: jingham
Subscribers: abidh, lldb-commits, leonid.mashinskiy
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D55318
llvm-svn: 353149
Summary:
These classes describe the details of the process we are about to
launch, and so they are naturally used by the launching code in the Host
module. Previously they were present in Target because that is the most
important (but by far not the only) user of the launching code.
Since the launching code has other customers, must of which do not care
about Targets, it makes sense to move these classes to the Host layer,
next to the launching code.
This move reduces the number of times that Target is included from host
to 8 (it used to be 14).
Reviewers: zturner, clayborg, jingham, davide, teemperor
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56602
llvm-svn: 353047
libc++ has programmable ABI versioning controllable with the _LIBCPP_ABI_VERSION
macro. Currently there are at least 3 settings used in real systems (1 as the
default, ndk1 for Anroid, Cr for Chromium).
Only the 1 and ndk1 cases were handled. This change relaxes the check to allow
any ABI version.
Differential Revision: https://reviews.llvm.org/D57466
llvm-svn: 352899
stored relative to VFRAME
Summary:
This patch makes LLDB able to retrieve proper values for function arguments and
local variables stored in PDB relative to VFRAME register.
Patch contains retrieval of corresponding FPO table entries from PDB and a
generic translator from FPO programs to DWARF expressions to get correct VFRAME
value.
Patch also improves variables-locations.test and makes this test passable on
x86.
Patch By: leonid.mashinsky
Reviewers: zturner, asmith, stella.stamenova, aleksandr.urakov
Reviewed By: zturner
Subscribers: arphaman, labath, mgorny, aprantl, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D55122
llvm-svn: 352845
Summary:
When we are creating a ClassTemplateSpecializationDecl in ParseTypeFromDWARF(...) we are not handling the case where variadic pack is empty in the specialization. This patch handles that case and adds a test to prevent future regressions.
Differential Revision: https://reviews.llvm.org/D57363
llvm-svn: 352677
This patch adds the file provider which is responsible for capturing
files used by LLDB.
When capturing a reproducer, we use a file collector that is very
similar to the one used in clang. For every file that we touch, we add
an entry with a mapping from its virtual to its real path. When we
decide to generate a reproducer we copy over the files and their
permission into to reproducer folder.
When replaying a reproducer, we load the VFS mapping and instantiate a
RedirectingFileSystem. The latter will transparently use the files
available in the reproducer.
I've tested this on two macOS machines with an artificial example.
Still, it is very likely that I missed some places where we (still) use
native file system calls. I'm hoping to flesh those out while testing
with more advanced examples. However, I will fix those things in
separate patches.
Differential revision: https://reviews.llvm.org/D54617
llvm-svn: 352538
This is a continuation of my quest to make the size 0 a supported value.
This reapplies r352394 with additional PDB parser fixes prepared by
Pavel Labath!
Differential Revision: https://reviews.llvm.org/D57273
llvm-svn: 352521
The two records aren't used by anything yet, but this part can be
separated out easily, so I am comitting it separately to simplify
reviews of the followup patch.
llvm-svn: 352507
Summary:
This patch adds the basic support of methods reconstruction by native PDB
plugin. It contains only most obvious changes (it processes LF_ONEMETHOD and
LF_METHOD records), some things still remain unsolved:
- mangled names retrieving;
- support of template methods.
Reviewers: zturner, labath, lemo, stella.stamenova
Reviewed by: zturner
Differential Revision: https://reviews.llvm.org/D56126
llvm-svn: 352464
Currently if a breakpoint site is already present, its ID will be returned, not the LLDB_INVALID_BREAK_ID.
On the other hand, Process::CreateBreakpointSite may have another reasons to return LLDB_INVALID_BREAK_ID.
llvm-svn: 352226
Summary:
The field `m_decompression_scratch_type` is only used when `HAVE_LIBCOMPRESSION` is
defined, which caused a warning which I fixed in rLLDB350675 by just marking the variable as always used.
This patch fixes this in a better way by only defining the variable (and the related `m_decompression_scratch`
variable) when `HAVE_LIBCOMPRESSION` is defined. This also required changing the way we handle
`HAVE_LIBCOMPRESSION` works, as this was previously always defined on macOS within the source file
but not in the header. Now it's always defined from within our config header when CMake defines it or when
we are on macOS.
The field initialization was moved to the header to prevent that we have `#ifdef` within our initializer list.
Reviewers: #lldb, jasonmolenda, sgraenitz, labath
Reviewed By: labath
Subscribers: labath, beanz, mgorny, lldb-commits, dblaikie
Differential Revision: https://reviews.llvm.org/D57011
llvm-svn: 352175
when the binary loaded in memory has a section that we cannot find
in the on-disk version. I added this warning out of an overabundance
of caution originally, but I've never seen an instance of it being
hit in the past few years, and there are some changes for the shared
cache on darwin systems where a segment is added when the shared
cache is constructed so we're now hitting this warning. I've decided
to remove it altogether.
<rdar://problem/46889346>
llvm-svn: 352158
We use UUID::fromOptionalData to read UUID's from the Mach-O files, so UUID's
of all 0's are invalid UUID's.
We also get uuid's from debugserver, which need to match the file UUID's. So
we need an API that treats "000000000" as invalid as well. Added that and use it.
Differential Revision: https://reviews.llvm.org/D57195
llvm-svn: 352122
Summary:
This addresses the issues raised in D56844. It removes the accessors from the
breakpad record structures by making the fields public. Also, I refactor the
UUID parsing code to remove hard-coded constants.
Reviewers: lemo
Subscribers: clayborg, lldb-commits
Differential Revision: https://reviews.llvm.org/D57037
llvm-svn: 352021
This patch extends SymbolFileBreakpad::AddSymbols to include the symbols
from the FUNC records too. These symbols come from the debug info and
have a size associated with them, so they are given preference in case
there is a PUBLIC record for the same address.
To achieve this, I first pre-process the symbols into a temporary
DenseMap, and then insert the uniqued symbols into the module's symtab.
Reviewers: clayborg, lemo, zturner
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56590
llvm-svn: 351781
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Summary:
This centralizes parsing of breakpad records, which was previously
spread out over ObjectFileBreakpad and SymbolFileBreakpad.
For each record type X there is a separate breakpad::XRecord class, and
an associated parse function. The classes just store the information in
the breakpad records in a more accessible form. It is up to the users to
determine what to do with that data.
This separation also made it possible to write some targeted tests for
the parsing code, which was previously unaccessible, so I write a couple
of those too.
Reviewers: clayborg, lemo, zturner
Reviewed By: clayborg
Subscribers: mgorny, fedor.sergeev, lldb-commits
Differential Revision: https://reviews.llvm.org/D56844
llvm-svn: 351541
In the original reproducer design, I expected providers to be more
dynamic than they turned out. For example, we don't have any instances
where one provider has multiple files. Additionally, I expected there to
be less locality between capture and replay, with the provider being
defined in one place and the replay code to live in another. Both
contributed to the design of the provider info.
This patch refactors the reproducer info to be something static. This
means less magic strings and better type checking. The new design still
allows for the capture and replay code to live in different places as
long as they both have access to the new statically defined info class.
I didn't completely get rid of the index, because it is useful for (1)
sanity checking and (2) knowing what files are used by the reproducer.
Differential revision: https://reviews.llvm.org/D56814
llvm-svn: 351501
This reapplies commit r351330, which was reverted due to a failing test on
macos. The failure was because the SymbolVendor used on MacOS was stricter than
the default (or ELF) symbol vendor, and rejected the symbol file because it's
UUID did not match the object file.
This version of the patch adds a uuid load command to the test macho file to
make sure the UUIDs match.
llvm-svn: 351447
This reapplies r350802, which was reverted because of issues with
parsing posix-style paths on windows hosts (and vice-versa). These have
since been fixed in r351328, and lldb should now recognise the path
style used in a dwarf compile unit correctly.
llvm-svn: 351435
This patch changes the behavior when printing C++ function references:
where we previously would get a <could not determine size>, there is
now a <no summary available>. It's not clear to me whether this is a
bug or an omission, but it's one step further than LLDB previously
got.
Differential Revision: https://reviews.llvm.org/D56798
llvm-svn: 351376
Summary:
Adding a breakpad symbol file to an existing MachO module with "target symbols
add" currently works only if one's host platform is a mac. This is
because SymbolVendorMacOSX (which is the one responsible for loading
symbols for MachO files) is conditionally compiled for the mac platform.
While we will sooner or later have a special symbol vendor for breakpad
files (to enable more advanced searching), and so this flow could be
made to work through that, it's not clear to me whether this should be a
requirement for the "target symbols add" flow to work. After all, since
the user has explicitly specified the symbol file to use, the symbol
vendor plugin's job is pretty much done.
This patch teaches the default symbol vendor to respect module's symbol
file spec, and load the symbol from that file if it is specified (and no
plugin requests any special handling).
Reviewers: clayborg, zturner, lemo
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56589
llvm-svn: 351330
Summary:
If we opened a file which was produced on system with different path
syntax, we would parse the paths from the debug info incorrectly.
The reason for that is that we would parse the paths as they were
native. For example this meant that on linux we would treat the entire
windows path as a single file name with no directory component, and then
we would concatenate that with the single directory component from the
DW_AT_comp_dir attribute. When parsing posix paths on windows, we would
at least get the directory separators right, but we still would treat
the posix paths as relative, and concatenate them where we shouldn't.
This patch attempts to remedy this by guessing the path syntax used in
each compile unit. (Unfortunately, there is no info in DWARF which would
give the definitive path style used by the produces, so guessing is all
we can do.) Currently, this guessing is based on the DW_AT_comp_dir
attribute of the compile unit, but this can be refined later if needed
(for example, the DW_AT_name of the compile unit may also contain some
useful info). This style is then used when parsing the line table of
that compile unit.
This patch is sufficient to make the line tables come out right, and
enable breakpoint setting by file name work correctly. Setting a
breakpoint by full path still has some kinks (specifically, using a
windows-style full path will not work on linux because the path will be
parsed as a linux path), but this will require larger changes in how
breakpoint setting works.
Reviewers: clayborg, zturner, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D56543
llvm-svn: 351328
The code in LLDB assumes that CompilerType and friends use the size 0
as a sentinel value to signal an error. This works for C++, where no
zero-sized type exists, but in many other programming languages
(including I believe C) types of size zero are possible and even
common. This is a particular pain point in swift-lldb, where extra
code exists to double-check that a type is *really* of size zero and
not an error at various locations.
To remedy this situation, this patch starts by converting
CompilerType::getBitSize() and getByteSize() to return an optional
result. To avoid wasting space, I hand-rolled my own optional data
type assuming that no type is larger than what fits into 63
bits. Follow-up patches would make similar changes to the ValueObject
hierarchy.
rdar://problem/47178964
Differential Revision: https://reviews.llvm.org/D56688
llvm-svn: 351214
This parameter was only ever used with the Module set, and
since a SymbolFile is tied to a module, the parameter turns
out to be entirely unnecessary. Furthermore, it doesn't make
a lot of sense to ask a caller to ask SymbolFile which is tied
to Module X to find types for Module Y, but that possibility
was open with the previous interface. By removing this
parameter from the API, it makes it harder to use incorrectly
as well as easier for an implementor to understand what it
needs to do.
llvm-svn: 351133
Every callsite was passing an empty SymbolContext, so this parameter
had no effect. Inside the DWARF implementation of this function,
however, there was one codepath that checked members of the
SymbolContext. Since no call-sites actually ever used this
functionality, it was essentially dead code, so I've deleted this
code path as well.
llvm-svn: 351132
This method took a SymbolContext but only actually cared about the
case where the m_function member was set. Furthermore, it was
intended to be implemented to parse blocks recursively despite not
documenting this in its name. So we change the name to indicate
that it should be recursive, while also limiting the function
parameter to be a Function&. This lets the caller know what is
required to use it, as well as letting new implementers know what
kind of inputs they need to be prepared to handle.
llvm-svn: 351131
Summary:
This patch allows to retrieve an address object for `ValueObject`'s children
retrieved through e.g. `GetChildAtIndex` or `GetChildMemberWithName`. It just
uses the corresponding method of the implementation object `m_impl` to achieve
that.
Reviewers: zturner, JDevlieghere, clayborg, labath, serge-sans-paille
Reviewed By: clayborg
Subscribers: leonid.mashinskiy, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D56147
llvm-svn: 351065
Previously all of these functions accepted a SymbolContext&.
While a CompileUnit is one member of a SymbolContext, there
are also many others, and by passing such a monolithic parameter
in this way it makes the requirements and assumptions of the
API unclear for both callers as well as implementors.
All these methods need is a CompileUnit. By limiting the
parameter type in this way, we simplify the code as well as
make it self-documenting for both implementers and users.
Differential Revision: https://reviews.llvm.org/D56564
llvm-svn: 350943
Summary:
This commit adds the glue code necessary to integrate the
SymbolFileBreakpad into the plugin system. Most of the methods are
stubbed out. The only method implemented method is AddSymbols, which
parses the PUBLIC "section" of the breakpad "object file", and fills out
the Module's symtab.
To enable testing this, I've made two additional changes:
- dump Symtab from the SymbolVendor class. The symtab was already being
dumped as a part of the object file dump, but that happened before
symbol vendor kicked in, so it did not reflect any symbols added
there.
- add ability to explicitly specify the external symbol file in
lldb-test (so that the object file could be linked with the breakpad
symbol file). To make things simpler, I've changed lldb-test from
consuming multiple inputs (and dumping their symbols) to having it
just process a single file per invocation. This was not a problem
since everyone was using it that way already.
Reviewers: clayborg, zturner, lemo, markmentovai, amccarth
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56173
llvm-svn: 350924
The code was assuming that the elf file will have a PT_LOAD segment
starting from the first byte of the file. While this is true for files
generated by most linkers (it's a way of saving space), it is not a
requirement. And files not satisfying this constraint can still be
perfectly executable. yaml2obj is one of the tools which produces files
like this.
This patch relaxes the check in ObjectFileELF to take the address of the
first PT_LOAD segment as the base address of the object (instead of the
one with the offset 0). Since the PT_LOAD segments are supposed to be
sorted according to the VM address, this entry will also be the one with
the lowest VM address.
If we ever run into files which don't have the PT_LOAD segments sorted,
we can easily change this code to return the lowest VM address as the
base address (if that is the correct thing to do for these files).
llvm-svn: 350923
The function SymbolFile::ParseTypes previously accepted a SymbolContext.
This makes it extremely difficult to implement faithfully, because you
have to account for all possible combinations of members being set in
the SymbolContext. On the other hand, no clients of this function
actually care about implementing this function to this strict of a
standard. AFAICT, there is actually only 1 client in the entire
codebase, and it is the function ParseAllDebugSymbols, which is itself
only called for testing purposes when dumping information. At this
call-site, the only field it sets is the CompileUnit, meaning that an
implementer of a SymbolFile need not worry about any examining or
handling any other fields which might be set.
By restricting this API to accept exactly a CompileUnit& and nothing
more, we can simplify the life of new SymbolFile plugin implementers by
making it clear exactly what the necessary and sufficient set of
functionality they need to implement is, while at the same time removing
some dead code that tried to handle other types of SymbolContext fields
that were never going to be set anyway.
Differential Revision: https://reviews.llvm.org/D56462
llvm-svn: 350889
Typedefs are represented as S_UDT records in the globals stream. This
creates a strange situation where "types" are actually represented as
"symbols", so they need special handling.
In order to test this, we don't just use lldb and print out some
variables causing the AST to get created, because variables whose type
is a typedef will have debug info referencing the original type, not the
typedef. So we use lldb-test instead which will parse all debug info in
the entire file. This exposed some problems with lldb-test and the
native reader, mainly that certain types of obscure symbols which we can
find when iterating every single record would trigger crashes. These
have been fixed as well so that lldb-test can be used to test this
functionality.
Differential Revision: https://reviews.llvm.org/D56461
llvm-svn: 350888
That is, remove many of the calls to Type::getNumContainedTypes(),
Type::subtypes(), and Type::getContainedType(N).
I'm not intending to remove these accessors -- they are
useful/necessary in some cases. However, removing the pointee type
from pointers would potentially break some uses, and reducing the
number of calls makes it easier to audit.
llvm-svn: 350835
This reverts commit r350802 because the test fails on windows. This
happens because we treat the paths as windows paths even though they
have linux path separators in the asm file. That results in wrong paths
being computed (\tmp\tmp\a.c instead of /tmp/a.c).
Reverting until I can figure out what to do with this.
llvm-svn: 350810
If a section name is exactly 8 bytes long (or has been truncated to 8
bytes), it will not contain the terminating nul character. This means
reading the name as a c string will pick up random data following the
name field (which happens to be the section vm size).
This fixes the name computation to avoid out-of-bounds access and adds a
test.
Reviewers: zturner, stella.stamenova
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56124
llvm-svn: 350809
Summary:
The concept of a base address was already present in the implementation
(it's needed for computing section load addresses properly), but it was
never exposed through this function. This fixes that.
llvm-svn: 350804
Summary:
The motivation for this is being able to write tests for the upcoming
breakpad line table parser, but this could be useful for testing the
low-level workings of any line table format. Or simply for viewing the
line table information with more detail (the brief format doesn't
include any of the flags for end_of_prologue and similar).
I've also removed the load_addresses argument from the
DumpCompileUnitLineTable function, as it wasn't being used anywhere.
Reviewers: clayborg, zturner
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D56315
llvm-svn: 350802
was working on something else.
DynamicLoaderDarwinKernel::SearchForKernelNearPC should have had
an early return if the pc value is not in high memory; add that.
The search for a kernel at 0x2000 offsets was a stopgap; it doesn't
need to be checked any longer.
llvm-svn: 350786
Summary:
This adds unnamed pipe support in PipeWindows to support communication between a debug server and child process.
Modify PipeWindows::CreateNew to support the creation of an unnamed pipe.
Rename the previous method that created a named pipe to PipeWindows::CreateNewNamed.
Reviewers: zturner, llvm-commits
Reviewed By: zturner
Subscribers: Hui, labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D56234
llvm-svn: 350784
ParseDeclsForContext was originally created to serve the very specific
case where the context is a function block. It was never intended to be
used for arbitrary DeclContexts, however due to the generic name, the
DWARF and PDB plugins implemented it in this way "just in case". Then,
lldb-test came along and decided to use it in that way.
Related to this, there are a set of functions in the SymbolFile class
interface whose requirements and expectations are not documented. For
example, if you call ParseCompileUnitFunctions, there's an inherent
requirement that you create entries in the underlying clang AST for
these functions as well as their signature types, because in order to
create an lldb_private::Function object, you have to pass it a
CompilerType for the parameter representing the signature.
On the other hand, there is no similar requirement (either inherent or
documented) if one were to call ParseDeclsForContext. Specifically, if
one calls ParseDeclsForContext, and some variable declarations, types,
and other things are added to the clang AST, is it necessary to create
lldb::Variable, lldb::Type, etc objects representing them? Nobody knows.
There is, however, an accidental requirement, because since all of the
plugins implemented this just in case, lldb-test came along and used
ParsedDeclsForContext, and then wrote check lines that depended on this.
When I went to try and implemented the NativePDB reader, I did not
adhere to this (in fact, from a layering perspective I went out of my
way to avoid it), and as a result the existing DIA PDB tests don't work
when the native PDB reader is enabled, because they expect that calling
ParseDeclsForContext will modify the *module's* view of symbols, and not
just the internal AST.
All of this confusion, however, can be avoided if we simply stick to
using ParseDeclsForContext for its original intended use case (blocks),
and use a different function (ParseAllDebugSymbols) for its intended use
case which is, unsuprisingly, to parse all the debug symbols (which is
all lldb-test really wanted to do anyway).
In the future, I would like to change ParseDeclsForContext to
ParseDeclsForFunctionBlock, then delete all of the dead code inside that
handles other types of DeclContexts (and probably even assert if the
DeclContext is anything other than a block).
A few PDB tests needed to be fixed up as a result of this, and this also
exposed a couple of bugs in the DIA PDB reader (doesn't matter much
since it should be going away soon, but worth mentioning) where the
appropriate AST entries weren't being created always.
Differential Revision: https://reviews.llvm.org/D56418
llvm-svn: 350764
Summary:
This is the result of the discussion in D55356, where it was suggested
as a solution to representing the addresses that logically belong to a
module in memory, but are not a part of any of its sections.
The ELF PT_LOAD segments are similar to the MachO "load commands",
except that the relationship between them and the object file sections
is a bit weaker. While in the MachO case, the sections belonging to a
specific segment are placed directly inside it in the object file
logical structur, in the ELF case, the sections and segments form two
separate hierarchies. This means that it is in theory possible to create
an elf file where only a part of a section would belong to some segment
(and another part to a different one). However, I am not aware of any
tool which would produce such a file (and most tools will have problems
ingesting them), so this means it is still possible to follow the MachO
model and make sections children of the PT_LOAD segments.
In case we run into (corrupt?) files with overlapping sections, I have
added code (and tests) which adjusts the sizes and/or drops the offending
sections in order to present a reasonable image to the upper layers of
LLDB. This is mostly done for completeness, as I don't anticipate
running into this situation in the real world. However, if we do run
into it, and the current behavior is not suitable for some reason, we
can implement this logic differently.
Reviewers: clayborg, jankratochvil, krytarowski, joerg, espindola
Subscribers: emaste, arichardson, lldb-commits
Differential Revision: https://reviews.llvm.org/D55998
llvm-svn: 350742
LLVM added wrappers to std::sort (r327219) that randomly shuffle the
container before sorting. The goal is to uncover non-determinism due to
undefined sorting order of objects having the same key.
This can be enabled with -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON.
llvm-svn: 350679
Summary: The member is private and unused if HAVE_LIBCOMPRESSION is undefined, which triggers Clang's -Wunused-private-field warning.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56458
llvm-svn: 350675
I was looking at the code in BreakpointList.cpp and found it deserved a
quick cleanup.
- Use std::vector instead of a std::list.
- Extract duplicate code for notifying.
- Remove code duplication when returning a const value.
- Use range-based for loop.
- Use early return in loops.
Differential revision: https://reviews.llvm.org/D56425
llvm-svn: 350659
Summary:
The target was being used in FinalizeFileActions to provide default
values for stdin/out/err. Also, most of the logic of this function was
very specific to how the lldb's Target class wants to launch processes,
so I, move it to Target::FinalizeFileActions, inverting the dependency.
The only piece of logic that was useful elsewhere (lldb-server) was the
part which sets up a pty and relevant file actions. I've kept this part
as ProcessLaunchInfo::SetUpPtyRedirection.
This makes ProcessLaunchInfo independent of any high-level lldb constructs.
Reviewers: zturner, jingham, teemperor
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56196
llvm-svn: 350617
Summary:
This patch allows ObjectFileBreakpad to parse the contents of Breakpad
files into sections. This sounds slightly odd at first, but in essence
its not too different from how other object files handle things. For
example in elf files, the symtab section consists of a number of
"records", where each record represents a single symbol. The same is
true for breakpad's PUBLIC section, except in this case, the records will be
textual instead of binary.
To keep sections contiguous, I create a new section every time record
type changes. Normally, the breakpad processor will group all records of
the same type in one block, but the format allows them to be intermixed,
so in general, the "object file" may contain multiple sections with the
same record type.
Reviewers: clayborg, zturner, lemo, markmentovai, amccarth
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D55434
llvm-svn: 350511
Summary:
The Debuffer object was being used in "GetListenerForProcess" to provide
a default listener object if one was not specified in the launch_info
object.
Since all the callers of this function immediately passed the result to
Target::CreateProcess, it was easy to move this logic there instead.
This brings us one step closer towards being able to move the LaunchInfo
classes to the Host layer (which is there the launching code that
consumes them lives).
Reviewers: zturner, jingham, teemperor
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56174
llvm-svn: 350510
D55859 changed "external tools or libraries" to "external sources" according to
Pavel Labath. Now it is changed sort of back to "external tools and
repositories" according to Adrian Prantl.
https://reviews.llvm.org/D55859#1345881
llvm-svn: 350479
Summary:
Simplify SWIG invocation and handling of generated files.
The `swig_wrapper` target can generate `LLDBWrapPython.cpp` and `lldb.py` in its own binary directory, so we can get rid of a few global variables and their logic. We can use the swig_wrapper's BINARY_DIR target property to refer to it and liblldb's LIBRARY_OUTPUT_DIRECTORY to refer to the framework/shared object output directory.
Reviewers: JDevlieghere, aprantl, stella.stamenova, beanz, zturner, xiaobai
Reviewed By: aprantl
Subscribers: mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55332
llvm-svn: 350393
Summary:
Add features to LLDB CMake builds that have so far only been available in Xcode. Clean up a few inconveniences and prepare further improvements.
Options:
* `LLDB_FRAMEWORK_BUILD_DIR` determines target directory (in build-tree)
* `LLDB_FRAMEWORK_INSTALL_DIR` **only** determines target directory in install-tree
* `LLVM_EXTERNALIZE_DEBUGINFO` allows externalized debug info (dSYM on Darwin, emitted to `bin`)
* `LLDB_FRAMEWORK_TOOLS` determines which executables will be copied to the framework's Resources (dropped symlinking, removed INCLUDE_IN_SUITE, removed dummy targets)
Other changes:
* clean up `add_lldb_executable()`
* include `LLDBFramework.cmake` from `source/API/CMakeLists.txt`
* use `*.plist.in` files, which are typical for CMake and independent from Xcode
* add clang headers to the framework bundle
Reviewers: xiaobai, JDevlieghere, aprantl, davide, beanz, stella.stamenova, clayborg, labath
Reviewed By: aprantl
Subscribers: friss, mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55328
llvm-svn: 350391
Jason Molenda