Implement GetSharedLibraryInfoAddress

Summary:
This is the third patch to improve module loading in a series that started here (where I explain the motivation and solution): D62499

Add functions to

Implement GetSharedLibraryInfoAddress

Summary:
This is the third patch to improve module loading in a series that started here (where I explain the motivation and solution): D62499

Add functions to read the r_debug location to know where the linked list of loaded libraries are so I can generate the `xfer:libraries-svr4` packet.
I'm also using this function to implement `GetSharedLibraryInfoAddress` that was "not implemented" for linux.
Most of this code was inspired by the current ds2 implementation here: https://github.com/facebook/ds2/blob/master/Sources/Target/POSIX/ELFProcess.cpp.

Reviewers: clayborg, xiaobai, labath

Reviewed By: clayborg, labath

Subscribers: emaste, krytarowski, mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D62501

llvm-svn: 363458

show more ...

Add support to read aux vector values

Summary:
This is the second patch to improve module loading in a series that started here (where I explain the motivation and solution): https://reviews.llvm.or

Add support to read aux vector values

Summary:
This is the second patch to improve module loading in a series that started here (where I explain the motivation and solution): https://reviews.llvm.org/D62499

I need to read the aux vector to know where the r_debug map with the loaded libraries are.
The AuxVector class was made generic so it could be reused between the POSIX-DYLD plugin and NativeProcess*. The class itself ended up in the ProcessUtility plugin.

Reviewers: clayborg, xiaobai, labath, JDevlieghere

Reviewed By: clayborg, labath, JDevlieghere

Subscribers: emaste, JDevlieghere, mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D62500

llvm-svn: 363098

show more ...

Simplify Triple::ppc64{,le} checks with Triple::isPPC64()

While here, update some ppc64le specific check to isPPC64(), if it
applies to big-endian as well, in the hope that it will ease the support

Simplify Triple::ppc64{,le} checks with Triple::isPPC64()

While here, update some ppc64le specific check to isPPC64(), if it
applies to big-endian as well, in the hope that it will ease the support
of big-endian if people are interested in this area. The big-endian
variant is used by at least FreeBSD, Gentoo Linux, Adélie Linux, and
Void Linux.

llvm-svn: 360868

show more ...

Simplify ArchSpec::IsMIPS()

llvm-svn: 360865

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.

I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.

Differential revision: https://reviews.llvm.org/D60508

llvm-svn: 358135

show more ...

Replace 'ap' with 'up' suffix in variable names. (NFC)

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

Replace 'ap' with 'up' suffix in variable names. (NFC)

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

show more ...

Fix incorrect log messages in NativeProcessLinux (pr40588)

The "signal" argument was removed from the MonitorCallback function, but
not from the log statements within it. This wasn't noticed because

Fix incorrect log messages in NativeProcessLinux (pr40588)

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

show more ...

Move FileAction, ProcessInfo and ProcessLaunchInfo from Target to Host

Summary:
These classes describe the details of the process we are about to
launch, and so they are naturally used by the launch

Move FileAction, ProcessInfo and ProcessLaunchInfo from Target to Host

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

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
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

show more ...

Remove /proc/pid/maps parsing code from NativeProcessLinux

A utility function doing this was added in r349182, so use that instead.

llvm-svn: 349267

Remove header grouping comments.

This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdate

Remove header grouping comments.

This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.

llvm-svn: 346626

show more ...

NativeProcessProtocol: Simplify breakpoint setting code

Summary:
A fairly simple operation as setting a breakpoint (writing a breakpoint
opcode) at a given address was going through three classes:
N

NativeProcessProtocol: Simplify breakpoint setting code

Summary:
A fairly simple operation as setting a breakpoint (writing a breakpoint
opcode) at a given address was going through three classes:
NativeProcessProtocol which called NativeBreakpointList, which then
called SoftwareBrekpoint, only to end up again in NativeProcessProtocol
to do the actual writing itself. This is unnecessarily complex and can
be simplified by moving all of the logic into NativeProcessProtocol
class itself, removing a lot of boilerplate.

One of the reeasons for this complexity was that (it seems)
NativeBreakpointList class was meant to hold both software and hardware
breakpoints. However, that never materialized, and hardware breakpoints
are stored in a separate map holding only hardware breakpoints.
Essentially, this patch makes software breakpoints follow that approach
by replacing the heavy SoftwareBraekpoint with a light struct of the
same name, which holds only the data necessary to describe one
breakpoint. The rest of the logic is in the main class. As, at the
lldb-server level, handling software and hardware breakpoints is very
different, this seems like a reasonable state of things.

Reviewers: krytarowski, zturner, clayborg

Subscribers: mgorny, lldb-commits

Differential Revision: https://reviews.llvm.org/D52941

llvm-svn: 346093

show more ...

[FileSystem] Move path resolution logic out of FileSpec

This patch removes the logic for resolving paths out of FileSpec and
updates call sites to rely on the FileSystem class instead.

Differential

[FileSystem] Move path resolution logic out of FileSpec

This patch removes the logic for resolving paths out of FileSpec and
updates call sites to rely on the FileSystem class instead.

Differential revision: https://reviews.llvm.org/D53915

llvm-svn: 345890

show more ...

Pull FixupBreakpointPCAsNeeded into base class

Summary:
This function existed (with identical code) in both NativeProcessLinux
and NativeProcessNetBSD, and it is likely that it would be useful to an

Pull FixupBreakpointPCAsNeeded into base class

Summary:
This function existed (with identical code) in both NativeProcessLinux
and NativeProcessNetBSD, and it is likely that it would be useful to any
future implementation of NativeProcessProtocol.

Therefore I move it to the base class.

Reviewers: krytarowski

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D52719

llvm-svn: 343683

show more ...

Pull GetSoftwareBreakpointPCOffset into base class

Summary:
This function encodes the knowledge of whether the PC points to the
breakpoint instruction of the one following it after the breakpoint is

Pull GetSoftwareBreakpointPCOffset into base class

Summary:
This function encodes the knowledge of whether the PC points to the
breakpoint instruction of the one following it after the breakpoint is
"hit". This behavior mainly(*) depends on the architecture and not on the
OS, so it makes sense for it to be implemented in the base class, where
it can be shared between different implementations (Linux and NetBSD
atm).

(*) It is possible for an OS to expose a different API, perhaps by doing
some fixups in the kernel. In this case, the implementation can override
this function to implement custom behavior.

Reviewers: krytarowski, zturner

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D52532

llvm-svn: 343409

show more ...

NativeProcessProtocol: Sink ReadMemoryWithoutTrap into base class

The two existing implementations have the function implemented
identically, and there's no reason to believe that this would be
diff

NativeProcessProtocol: Sink ReadMemoryWithoutTrap into base class

The two existing implementations have the function implemented
identically, and there's no reason to believe that this would be
different for other implementations.

llvm-svn: 342167

show more ...

Speculative fix for NetBSD bot for r341758

llvm-svn: 341759

Re-commit "Modernize NativeProcessProtocol::GetSoftwareBreakpointTrapOpcode"

This recommits r341487, which was reverted due to failing tests with
clang. It turned out I had incorrectly expected that

Re-commit "Modernize NativeProcessProtocol::GetSoftwareBreakpointTrapOpcode"

This recommits r341487, which was reverted due to failing tests with
clang. It turned out I had incorrectly expected that the literal arrays
passed to ArrayRef constructor will have static (permanent) storage.
This was only the case with gcc, while clang was constructing them on
stack, leading to dangling pointers when the function returns.

The fix is to explicitly assign static storage duration to the opcode
arrays.

llvm-svn: 341758

show more ...

Revert "Modernize NativeProcessProtocol::GetSoftwareBreakpointTrapOpcode"

This reverts commit r341487. Jan Kratochvil reports it breaks LLDB when
compiling with clang.

llvm-svn: 341747

Modernize NativeProcessProtocol::GetSoftwareBreakpointTrapOpcode

return the opcode as a Expected<ArrayRef> instead of a
Status+pointer+size combo.

I also move the linux implementation to the base c

Modernize NativeProcessProtocol::GetSoftwareBreakpointTrapOpcode

return the opcode as a Expected<ArrayRef> instead of a
Status+pointer+size combo.

I also move the linux implementation to the base class, as the trap
opcodes are likely to be the same for all/most implementations of the
class (except the arm one, where linux chooses a different opcode than
what the arm spec recommends, which I keep linux-specific).

llvm-svn: 341487

show more ...

Move RegisterValue,Scalar,State from Core to Utility

These three classes have no external dependencies, but they are used
from various low-level APIs. Moving them down to Utility improves
overall co

Move RegisterValue,Scalar,State from Core to Utility

These three classes have no external dependencies, but they are used
from various low-level APIs. Moving them down to Utility improves
overall code layering (although it still does not break any particular
dependency completely).

The XCode project will need to be updated after this change.

Differential Revision: https://reviews.llvm.org/D49740

llvm-svn: 339127

show more ...

Delete dead code in NativeProcessLinux

As far as I can tell, this code has always been guarded by `#if 0`. If
this is useful code, it can be added back.

llvm-svn: 334333

Reflow paragraphs in comments.

This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to r

Reflow paragraphs in comments.

This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.

FYI, the script I used was:

import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue

if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)

continue

if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""

out.write(line)

os.rename(tmp, sys.argv[1])

Differential Revision: https://reviews.llvm.org/D46144

llvm-svn: 331197

show more ...

[LLDB][PPC64] Fixed next blocked forever at same line

Summary:
The PC corresponding to the breakpoint was being calculated wrongly,
which was causing LLDB to never go past the first breakpoint, when

[LLDB][PPC64] Fixed next blocked forever at same line

Summary:
The PC corresponding to the breakpoint was being calculated wrongly,
which was causing LLDB to never go past the first breakpoint, when
there was a second one adjacent to it.

Reviewers: clayborg, labath

Reviewed By: clayborg, labath

Subscribers: anajuliapc, alexandreyy, lbianc

Differential Revision: https://reviews.llvm.org/D43344
Patch by Leandro Lupori <[email protected]>.

llvm-svn: 325728

show more ...

Remove ObjectFile usage from HostLinux::GetProcessInfo

Summary:
The ObjectFile class was used to determine the architecture of a running
process by inspecting it's main executable. There were two is

Remove ObjectFile usage from HostLinux::GetProcessInfo

Summary:
The ObjectFile class was used to determine the architecture of a running
process by inspecting it's main executable. There were two issues with
this:
- it's in the wrong layer
- the call can be very expensive (it can end up computing the crc of the
whole file).

Since the process is running on the host, ideally we would be able to
just query the data straight from the OS like darwin does, but there
doesn't seem to be a reasonable way to do that. So, this fixes the
layering issue by using the llvm object library to inspect the file.
Since we know the process is already running on the host, we just need
to peek at a few bytes of the elf header to determine whether it's 32-
or 64-bit (which should make this faster as well).

Pretty much the same logic was implemented in
NativeProcessProtocol::ResolveProcessArchitecture, so I delete this
logic and replace calls with GetProcessInfo.

Reviewers: eugene, krytarowski

Subscribers: mgorny, hintonda, lldb-commits

Differential Revision: https://reviews.llvm.org/D42488

llvm-svn: 323637

show more ...