Add a darwin platform setting to specify which exceptions debugserver
should not receive as exceptions (some will get converted to BSD
signals instead). This is really the only stable way to ensure

Add a darwin platform setting to specify which exceptions debugserver
should not receive as exceptions (some will get converted to BSD
signals instead). This is really the only stable way to ensure that
a Mach exception gets converted to it's equivalent BSD signal. For
programs that rely on BSD signal handlers, this has to happen or you
can't even get the program to invoke the signal handler when under
the debugger.

This builds on a previous solution to this problem which required you
start debugserver with the -U flag. This was not very discoverable
and required lldb be the one to launch debugserver, which is not always
the case.

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

show more ...

[debugserver] Add option to propagate SIGSEGV to target process

Adds a command line option that makes debugserver propagate the SIGSEGV
signal to the target process.

Motivation: I'm one of the main

[debugserver] Add option to propagate SIGSEGV to target process

Adds a command line option that makes debugserver propagate the SIGSEGV
signal to the target process.

Motivation: I'm one of the maintainers of Delve [1] a debugger for Go.
We use debugserver as our backend on macOS and one of the most often
reported bugs is that, on macOS, we don't propagate SIGSEGV back to the
target process [2]. Sometimes some programs will actually cause a
SIGSEGV, by design, and then handle it. Those programs can not be
debugged at all.

Since catching signals isn't very important for a Go debugger I'd much
rather have a command line option in debugserver that causes it to let
SIGSEGV go directly to the target process.

[1] https://github.com/go-delve/delve/
[2] https://github.com/go-delve/delve/issues/852

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

show more ...

[lldb] Update header guards to be consistent and compliant with LLVM (NFC)

LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pa

[lldb] Update header guards to be consistent and compliant with LLVM (NFC)

LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.

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

show more ...

Fix an over-suspend bug with LaunchInNewTerminalWithAppleScript sessions

When launching an inferior in a new terminal window via AppleScript
and the darwin-debug helper program, we could often end u

Fix an over-suspend bug with LaunchInNewTerminalWithAppleScript sessions

When launching an inferior in a new terminal window via AppleScript
and the darwin-debug helper program, we could often end up with the
inferior process having a too-high suspend count, and it would never
resume execution.

lldb tries to wait until darwin-debug has finished its work and has
launched the inferior (WaitForProcessToSIGSTOP) but this wasn't
working correctly - and cannot be made to work.

This patch removes WaitForProcessToSIGSTOP, adds a special tiny
segment to the darwin-debug executable so it can be identified as
that binary (ExecExtraSuspend), and adds code to debugserver to
detect this segment. When debugserver sees this segment, it notes
that the next exec will be done with a launch-suspended flag. When
the next exec happens, debugserver forces an extra task_resume when
we resume the inferior.

An alternative approach would be if lldb could detect when the
inferior has been launched by darwin-debug unambiguously; monitoring
when the unix socket between darwin-debug and lldb was closed would
have been a reasonable way to do this too.

<rdar://problem/29760580>

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

show more ...

Mark private unimplemented functions as deleted

Applies modernize-use-equals-delete to the LLDB code base and removes
the now redundant comments.

llvm-svn: 360751

[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 ...

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 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 ...

Add the ability for the task port to change when a process execs.

<rdar://problem/28476369>

llvm-svn: 282632

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging t

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.

llvm-svn: 280751

show more ...

Removed unused functions.

llvm-svn: 261768

Allow for a task port to change when we exec.

llvm-svn: 207699

Update MachVMMemory::PageSize to get the page size of a specific process
if we have an updated task_info call available; else fall back to getting
the default host-wide page size.

Update all uses of

Update MachVMMemory::PageSize to get the page size of a specific process
if we have an updated task_info call available; else fall back to getting
the default host-wide page size.

Update all uses of the vm page size to get it via MachVMMemory::PageSize().

<rdar://problem/13477763>, <rdar://problem/13498504>

llvm-svn: 178953

show more ...

<rdar://problem/13338758>

Make it configurable what to profile.
For Mac, we don't use the dirty page size yet and hence there is no need to gather that. This should be way better in not draining the

<rdar://problem/13338758>

Make it configurable what to profile.
For Mac, we don't use the dirty page size yet and hence there is no need to gather that. This should be way better in not draining the battery since we are operating between 0% to 0.1% on the Mac after this change.

llvm-svn: 176451

show more ...

<rdar://problem/12780259>

Prevent async and sync calls to get profile data from stomping on each other.
At the same time, don't use '$' as end delimiter per chunk of profile data.

llvm-svn: 168948

<rdar://problem/12720514> Sub-TLF: Provide service to profile the inferior

This allows client to query profiling states on the inferior.

llvm-svn: 168228

Added optional calls to lldb_private::Process for getting memory region info
from a process and hooked it up to the new packet that was recently added
to our GDB remote executable named debugserver.

Added optional calls to lldb_private::Process for getting memory region info
from a process and hooked it up to the new packet that was recently added
to our GDB remote executable named debugserver. Now Process has the following
new calls:

virtual Error
Process::GetMemoryRegionInfo (lldb::addr_t load_addr, MemoryRegionInfo &range_info);

virtual uint32_t
GetLoadAddressPermissions (lldb::addr_t load_addr);

Only the first one needs to be implemented by subclasses that can add this
support.

Cleaned up the way the new packet was implemented in debugserver to be more
useful as an API inside debugserver. Also found an error where finding a region
for an address actually will pick up the next region that follows the address
in the query so we also need ot make sure that the address we requested the
region for falls into the region that gets returned.

llvm-svn: 144976

show more ...

Remove the QAddressIsExecutable packet I added last night.

Add a more general purpose qMemoryRegionInfo packet which can
describe various attributes about a memory region. Currently it
will return

Remove the QAddressIsExecutable packet I added last night.

Add a more general purpose qMemoryRegionInfo packet which can
describe various attributes about a memory region. Currently it
will return the start address, size, and permissions (read, write,
executable) for the memory region. It may be possible to add
additional attributes in the future such as whether the region is
designated as stack memory or jitted code a la vmmap.

I still haven't implemented the lldb side of the code to use this
packet yet so there may be unexpected behavior - but the basic implementation looks
about right. I'll hook it up to lldb soon and fix any problems that crop up.

llvm-svn: 144175

show more ...

Add "QAddressIsExecutable" packet to debugserver. Used to test
whether a given address is in an executable region of memory or
not. I haven't written the lldb side that will use this packet it
hasn

Add "QAddressIsExecutable" packet to debugserver. Used to test
whether a given address is in an executable region of memory or
not. I haven't written the lldb side that will use this packet it
hasn't been tested yet but it's a simple enough bit of code.

I want to have this feature available for the unwinder code. When
we're stopped at an address with no valid symbol context, there are
a number of questions I'd like to ask --

is the current pc value in an executable region (e.g. did they
jump to unallocated/unexecutable memory? we know how to unwind
from here if so.)

Is the stack pointer or the frame pointer the correct register
to use to find the caller's saved pc value?

Once we're past the first frame we can trust things like eh_frame
and ABI unwind schemes but the first frame is challenging and having
a way to check potential addresses to see if they're executable or
not would help narrow down the possibilities a lot.

llvm-svn: 144074

show more ...

Basic infrastructure code to exploit malloc stack logging as available on Mac OS X to track the allocation history of pointers on the target process

llvm-svn: 139337

Retry task_for_pid a few times to avoid some cases where task_for_pid fails.

llvm-svn: 115184

Initial checkin of lldb code from internal Apple repo.

llvm-svn: 105619