Narrow the CompletionRequest API to being append-only.

Summary:
We currently allow any completion handler to read and manipulate the list of matches we
calculated so far. This leads to a few problem

Narrow the CompletionRequest API to being append-only.

Summary:
We currently allow any completion handler to read and manipulate the list of matches we
calculated so far. This leads to a few problems:

Firstly, a completion handler's logic can now depend on previously calculated results
by another handlers. No completion handler should have such an implicit dependency,
but the current API makes it likely that this could happen (or already happens). Especially
the fact that some completion handler deleted all previously calculated results can mess
things up right now.

Secondly, all completion handlers have knowledge about our internal data structures with
this API. This makes refactoring this internal data structure much harder than it should be.
Especially planned changes like the support of descriptions for completions are currently
giant patches because we have to refactor every single completion handler.

This patch narrows the contract the CompletionRequest has with the different handlers to:

1. A handler can suggest a completion.
2. A handler can ask how many suggestions we already have.

Point 2 obviously means we still have a dependency left between the different handlers, but
getting rid of this is too large to just append it to this patch.

Otherwise this patch just completely hides the internal StringList to the different handlers.

The CompletionRequest API now also ensures that the list of completions is unique and we
don't suggest the same value multiple times to the user. This property has been so far only
been ensured by the `Option` handler, but is now applied globally. This is part of this patch
as the OptionHandler is no longer able to implement this functionality itself.

Reviewers: jingham, davide, labath

Reviewed By: davide

Subscribers: lldb-commits

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

llvm-svn: 338151

show more ...

Replaced more boilerplate code with CompletionRequest (NFC)

Summary:
As suggested in D48796, this patch replaces even more internal calls that were using the old
completion API style with a single C

Replaced more boilerplate code with CompletionRequest (NFC)

Summary:
As suggested in D48796, this patch replaces even more internal calls that were using the old
completion API style with a single CompletionRequest. In some cases we also pass an option
vector/index, but as we don't always have this information, it currently is not part of the
CompletionRequest class.

The constructor of the CompletionRequest is now also more sensible. You only pass the
user input, cursor position and your list of matches to the request and the rest will be
inferred (using the same code we used before to calculate this). You also have to pass these
match window parameters to it, even though they are unused right now.

The patch shouldn't change any behavior.

Reviewers: jingham

Reviewed By: jingham

Subscribers: lldb-commits

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

llvm-svn: 337031

show more ...

Refactoring for for the internal command line completion API (NFC)

Summary:
This patch refactors the internal completion API. It now takes (as far as possible) a single
CompletionRequest object inst

Refactoring for for the internal command line completion API (NFC)

Summary:
This patch refactors the internal completion API. It now takes (as far as possible) a single
CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest
contains a common superset of the different parameters as far as it makes sense. This includes
the raw command line string and raw cursor position, which should make the `expr` command
possible to implement (at least without hacks that reconstruct the command line from the args).

This patch is not intended to change the observable behavior of lldb in any way. It's also as
minimal as possible and doesn't attempt to fix all the problems the API has.

Some Q&A:

Q: Why is this not fixing all the problems in the completion API?
A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the
smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future.
The patch also doesn't really change the internal information flow in the API, so that hopefully
saves us from ever having to revert and resubmit this humongous patch.

Q: Can we merge all the copy-pasted code in the completion methods
(like computing the current incomplete arg) into CompletionRequest class?
A: Yes, but it's out of scope for this patch.

Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern?
A: I don't want to add a getter that returns a reference to the internal integer. So we have
to use a temporary variable and the Getter/Setter instead. We don't throw exceptions
from what I can tell, so the behavior doesn't change.

Q: Why are we not owning the list of matches?
A: Because that's how the previous API works. But that should be fixed too (in another patch).

Q: Can we make the constructor simpler and compute some of the values from the plain command?
A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested
request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory
propagate the changes on the nested request back to the parent request if we don't want to change the
behavior too much).

Q: Can't we pass one const request object and then just return another result object instead of mixing
them together in one in/out parameter?
A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just
a single request object. If we make all input parameters read-only, we have a clear separation between what
is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters).

Q: Can we throw out the 'match' variables that are not implemented according to the comment?
A: We currently just forward them as in the old code to the different methods, even though I think
they are really not used. We can easily remove and readd them once every single completion method just
takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user.

Reviewers: davide, jingham, labath

Reviewed By: jingham

Subscribers: mgorny, friss, lldb-commits

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

llvm-svn: 336146

show more ...

[FileSpec] Make style argument mandatory for SetFile. NFC

SetFile has an optional style argument which defaulted to the native
style. This patch makes that argument mandatory so clients of the
FileS

[FileSpec] Make style argument mandatory for SetFile. NFC

SetFile has an optional style argument which defaulted to the native
style. This patch makes that argument mandatory so clients of the
FileSpec class are forced to think about the correct syntax.

At the same time this introduces a (protected) convenience method to
update the file from within the FileSpec class that keeps the current
style.

These two changes together prevent a potential pitfall where the style
might be forgotten, leading to the path being updated and the style
unintentionally being changed to the host style.

llvm-svn: 334663

show more ...

Remove append parameter to FindGlobalVariables

Summary:
As discussed in https://bugs.llvm.org/show_bug.cgi?id=37317,
FindGlobalVariables does not properly handle the case where
append=false. As thi

Remove append parameter to FindGlobalVariables

Summary:
As discussed in https://bugs.llvm.org/show_bug.cgi?id=37317,
FindGlobalVariables does not properly handle the case where
append=false. As this doesn't seem to be used in the tree, this patch
removes the parameter entirely.

Reviewers: clayborg, jingham, labath

Reviewed By: clayborg

Subscribers: aprantl, lldb-commits, kubamracek, JDevlieghere

Differential Revision: https://reviews.llvm.org/D46885
Patch by Tom Tromey <[email protected]>.

llvm-svn: 333639

show more ...

Use the UUID from the minidump's CodeView Record for placeholder modules

This change adds support for two types of Minidump CodeView records:

PDB70 (reference: https://crashpad.chromium.org/doxygen

Use the UUID from the minidump's CodeView Record for placeholder modules

This change adds support for two types of Minidump CodeView records:

PDB70 (reference: https://crashpad.chromium.org/doxygen/structcrashpad_1_1CodeViewRecordPDB70.html)
This is by far the most common record type.

ELF BuildID (found in Breakpad/Crashpad generated minidumps)
This would set a proper UUID for placeholder modules, in turn enabling
an accurate match with local module images.

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

llvm-svn: 331394

show more ...

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

Improve LLDB's handling of non-local minidumps

Normally, LLDB is creating a high-fidelity representation of a live
process, including a list of modules and sections, with the
associated memory addr

Improve LLDB's handling of non-local minidumps

Normally, LLDB is creating a high-fidelity representation of a live
process, including a list of modules and sections, with the
associated memory address ranges. In order to build the module and
section map LLDB tries to locate the local module image (object file)
and will parse it.

This does not work for postmortem debugging scenarios where the crash
dump (minidump in this case) was captured on a different machine.

Fortunately the minidump format encodes enough information about
each module's memory range to allow us to create placeholder modules.
This enables most LLDB functionality involving address-to-module
translations.

Also, we may want to completly disable the search for matching
local object files if we load minidumps unless we can prove that the
local image matches the one from the crash origin.
(not part of this change, see: llvm.org/pr35193)

Example: Identify the module from a stack frame PC:

Before:
thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14
frame #0: 0x00164d14
frame #1: 0x00167c79
frame #2: 0x00167e6d
frame #3: 0x7510336a
frame #4: 0x77759882
frame #5: 0x77759855

After:
thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14
frame #0: 0x00164d14 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
frame #1: 0x00167c79 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
frame #2: 0x00167e6d C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
frame #3: 0x7510336a C:\Windows\SysWOW64\kernel32.dll
frame #4: 0x77759882 C:\Windows\SysWOW64\ntdll.dll
frame #5: 0x77759855 C:\Windows\SysWOW64\ntdll.dll

Example: target modules list

Before:
error: the target has no associated executable images

After:
[ 0] C:\Windows\System32\MSVCP120D.dll
[ 1] C:\Windows\SysWOW64\kernel32.dll
[ 2] C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe
[ 3] C:\Windows\System32\MSVCR120D.dll
[ 4] C:\Windows\SysWOW64\KERNELBASE.dll
[ 5] C:\Windows\SysWOW64\ntdll.dll

NOTE: the minidump format also includes the debug info GUID, so we can
fill-in the module UUID from it, but this part was excluded from this change
to keep the changes simple (the LLDB UUID is hardcoded to be either 16 or
20 bytes, while the CodeView GUIDs are normally 24 bytes)

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

llvm-svn: 330302

show more ...

Move Args.cpp from Interpreter to Utility

Summary:
The Args class is used in plenty of places besides the command
interpreter (e.g., anything requiring an argc+argv combo, such as when
launching a p

Move Args.cpp from Interpreter to Utility

Summary:
The Args class is used in plenty of places besides the command
interpreter (e.g., anything requiring an argc+argv combo, such as when
launching a process), so it needs to be in a lower layer. Now that the
class has no external dependencies, it can be moved down to the Utility
module.

This removes the last (direct) dependency from the Host module to
Interpreter, so I remove the Interpreter module from Host's dependency
list.

Reviewers: zturner, jingham, davide

Subscribers: mgorny, lldb-commits

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

llvm-svn: 330200

show more ...

Move Args::StringTo*** functions to a new OptionArgParser class

Summary:
The idea behind this is to move the functionality which depend on other lldb
classes into a separate class. This way, the Arg

Move Args::StringTo*** functions to a new OptionArgParser class

Summary:
The idea behind this is to move the functionality which depend on other lldb
classes into a separate class. This way, the Args class can be turned
into a lightweight arc+argv wrapper and moved into the lower lldb
layers.

Reviewers: jingham, zturner

Subscribers: lldb-commits

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

llvm-svn: 329677

show more ...

Re-land: [lldb] Use vFlash commands when writing to target's flash memory regions

The difference between this and the previous patch is that now we use
ELF physical addresses only for loading object

Re-land: [lldb] Use vFlash commands when writing to target's flash memory regions

The difference between this and the previous patch is that now we use
ELF physical addresses only for loading objects into the target (and the
rest of the module load address logic still uses virtual addresses).

Summary:
When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup.

- Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address.
- Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications
- Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region

Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html

Reviewers: clayborg, labath

Reviewed By: labath

Subscribers: llvm-commits, arichardson, emaste, mgorny, lldb-commits

Differential Revision: https://reviews.llvm.org/D42145
Patch by Owen Shaw <[email protected]>.

llvm-svn: 327970

show more ...

Remove custom TimePoint-formatting code

This was a temporary thing, until llvm has proper support for formatting
time. That time has come, so we can remove the relevant code. There
should be no chan

Remove custom TimePoint-formatting code

This was a temporary thing, until llvm has proper support for formatting
time. That time has come, so we can remove the relevant code. There
should be no change in the format of the time.

llvm-svn: 319048

show more ...

Remove extra minuses from command option

Reviewers: labath, abidh, clayborg, ki.stfu

Reviewed By: labath, abidh, clayborg, ki.stfu

Subscribers: clayborg, ki.stfu, lldb-commits

Differential Revisi

Remove extra minuses from command option

Reviewers: labath, abidh, clayborg, ki.stfu

Reviewed By: labath, abidh, clayborg, ki.stfu

Subscribers: clayborg, ki.stfu, lldb-commits

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

llvm-svn: 318846

show more ...

Implement interactive command interruption

The core of this change is the new CommandInterpreter::m_command_state,
which models the state transitions for interactive commands, including
an "interrup

Implement interactive command interruption

The core of this change is the new CommandInterpreter::m_command_state,
which models the state transitions for interactive commands, including
an "interrupted" state transition.

In general, command interruption requires cooperation from the code
executing the command, which needs to poll for interruption requests
through CommandInterpreter::WasInterrupted().

CommandInterpreter::PrintCommandOutput() implements an optionally
interruptible printing of the command output, which for large outputs
was likely the longest blocking part.
(ex. target modules dump symtab on a complex binary could take 10+ minutes)

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

llvm-svn: 315037

show more ...

Revert patch r313904, as it breaks "command source" and in
particular causes lldb to die on startup if you have a ~/.lldbinit file.

I filed:

https://bugs.llvm.org/show_bug.cgi?id=34758

to cover f

Revert patch r313904, as it breaks "command source" and in
particular causes lldb to die on startup if you have a ~/.lldbinit file.

I filed:

https://bugs.llvm.org/show_bug.cgi?id=34758

to cover fixing the bug.

llvm-svn: 314371

show more ...

[LLDB] Implement interactive command interruption

The core of this change is the new CommandInterpreter::m_command_state, which
models the state transitions for interactive commands, including an
"i

[LLDB] Implement interactive command interruption

The core of this change is the new CommandInterpreter::m_command_state, which
models the state transitions for interactive commands, including an
"interrupted" state transition.

In general, command interruption requires cooperation from the code executing
the command, which needs to poll for interruption requests through
CommandInterpreter::WasInterrupted().

CommandInterpreter::PrintCommandOutput() implements an optionally
interruptible printing of the command output, which for large outputs was
likely the longest blocking part. (ex. target modules dump symtab on a
complex binary could take 10+ minutes)

patch by lemo

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

llvm-svn: 313904

show more ...

Extend 'target symbols add' to load symbols from a given module

Now -shlib flag can be provided alongside with names of symbols files:

(lldb) target symbols add --shlib stripper-lib.so unstripper-l

Extend 'target symbols add' to load symbols from a given module

Now -shlib flag can be provided alongside with names of symbols files:

(lldb) target symbols add --shlib stripper-lib.so unstripper-lib.so

This is helpful when default matching mechanisms by name and UUID
can't find a module, and the user needs to explicitly specify
which module the given symbol file belongs to.

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

llvm-svn: 308933

show more ...

Move Timer and TraceOptions from Core to Utility

Summary:
The classes have no dependencies, and they are used both by lldb and
lldb-server, so it makes sense for them to live in the lowest layers.

Move Timer and TraceOptions from Core to Utility

Summary:
The classes have no dependencies, and they are used both by lldb and
lldb-server, so it makes sense for them to live in the lowest layers.

Reviewers: zturner, jingham

Subscribers: emaste, mgorny, lldb-commits

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

llvm-svn: 306682

show more ...

Add debug_frame section support

Summary:
This is a beefed-up version of D33504, which adds support for dwarf 4
debug_frame section format.

The main difference here is that the decision whether to u

Add debug_frame section support

Summary:
This is a beefed-up version of D33504, which adds support for dwarf 4
debug_frame section format.

The main difference here is that the decision whether to use eh_frame or
debug_frame is done on a per-function basis instead of per-object file.
This is necessary because one module can contain both sections (for
example, the start files added by the linker will typically pull in
eh_frame), but we want to be able to access both, for maximum
information.

I also add unit test for parsing various CFI formats (eh_frame,
debug_frame v3 and debug_frame v4).

Reviewers: jasonmolenda, clayborg

Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha

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

llvm-svn: 306397

show more ...

Remove an expensive lock from Timer

The Timer destructor would grab a global mutex in order to update
execution time. Add a class to define a category once, statically; the
class adds itself to an a

Remove an expensive lock from Timer

The Timer destructor would grab a global mutex in order to update
execution time. Add a class to define a category once, statically; the
class adds itself to an atomic singly linked list, and thus subsequent
updates only need to use an atomic rather than grab a lock and perform a
hashtable lookup.

Differential Revision: https://reviews.llvm.org/D32823
Patch by Scott Smith <[email protected]>.

llvm-svn: 303058

show more ...

Rename Error -> Status.

This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.

A change of this magnitude cannot easily be done without
find and replace, but that h

Rename Error -> Status.

This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.

A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.

llvm-svn: 302872

show more ...

Delete some more dead includes.

This breaks the cycle between Target and PluginLanguageC++, reducing
the overall cycle count from 43 to 42.

llvm-svn: 298561

Resubmit FileSystem changes.

This was originall reverted due to some test failures in
ModuleCache and TestCompDirSymlink. These issues have all
been resolved and the code now passes all tests.

Dif

Resubmit FileSystem changes.

This was originall reverted due to some test failures in
ModuleCache and TestCompDirSymlink. These issues have all
been resolved and the code now passes all tests.

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

llvm-svn: 297300

show more ...

Revert "Use LLVM for all stat-related functionality."

this reverts r297116 because it breaks the unittests and
TestCompDirSymlink. The ModuleCache unit test is trivially fixable, but
the CompDirSyml

Revert "Use LLVM for all stat-related functionality."

this reverts r297116 because it breaks the unittests and
TestCompDirSymlink. The ModuleCache unit test is trivially fixable, but
the CompDirSymlink failure is a symptom of a deeper problem: llvm's stat
functionality is not a drop-in replacement for lldb's. The former is
based on stat(2) (which does symlink resolution), while the latter is
based on lstat(2) (which does not).

This also reverts subsequent build fixes (r297128, r297120, 297117) and
r297119 (Remove FileSpec dependency on FileSystem) which builds on top
of this.

llvm-svn: 297139

show more ...

Use LLVM for all stat-related functionality.

This deletes LLDB's FileType enumeration and replaces all
users, and all calls to functions that check whether a file
exists etc with corresponding calls

Use LLVM for all stat-related functionality.

This deletes LLDB's FileType enumeration and replaces all
users, and all calls to functions that check whether a file
exists etc with corresponding calls to LLVM.

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

llvm-svn: 297116

show more ...