[lldb] Update ProcessLauncherWinows to new Status API

[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute.

Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildb

[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute.

Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes.

The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const.

Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString:

ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const;

This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result.

The patch:
- Removes the non const GetDirectory() and GetFilename() get accessors
- Adds set accessors to replace the above functions: SetDirectory() and SetFilename().
- Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites
- Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently.

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

show more ...

[lldb] Remove some anonymous namespaces

.. and reduce the scope of others. They don't follow llvm coding
standards (which say they should be used only when the same effect
cannot be achieved with th

[lldb] Remove some anonymous namespaces

.. and reduce the scope of others. They don't follow llvm coding
standards (which say they should be used only when the same effect
cannot be achieved with the static keyword), and they set a bad example.

show more ...

[lldb] Rename StringRef _lower() method calls to _insensitive()

[Windows] Fix limit on command line size

This reapplies commit d4020ef7c474, reverted in ac0edc55887b because it
broke build of LLDB. This commit contains appropriate changes for LLDB.
The original

[Windows] Fix limit on command line size

This reapplies commit d4020ef7c474, reverted in ac0edc55887b because it
broke build of LLDB. This commit contains appropriate changes for LLDB.
The original commit message is below.

Documentation on CreateProcessW states that maximal size of command line
is 32767 characters including ternimation null character. In the
function llvm::sys::commandLineFitsWithinSystemLimits this limit was set
to 32768. As a result if command line was exactly 32768 characters long,
a response file was not created and CreateProcessW was called with
too long command line.

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

show more ...

Recommit "[lldb] Fix TestSettings.test_pass_host_env_vars on windows"

This patch was reverted because it introduced a failure in
TestHelloWorld.py. The reason for that was running "ls" shell command

Recommit "[lldb] Fix TestSettings.test_pass_host_env_vars on windows"

This patch was reverted because it introduced a failure in
TestHelloWorld.py. The reason for that was running "ls" shell command
failed as it was evaluated in an environment with an empty path. This
has now been fixed with D77123, which ensures that all shell commands
inherit the host environment, so this patch should be safe to recommit.

The original commit message was:

A defensive check in ProcessLauncherWindows meant that we would never
attempt to launch a process with a completely empty environment -- the
host environment would be used instead. Instead, I make the function add
an extra null wchar_t at the end of an empty environment. The
documentation on this is a bit fuzzy, but it seems to be what is needed
to make windows accept these kinds of environments.

Reviewers: amccarth, friss

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

show more ...

Revert "[lldb] Fix TestSettings.test_pass_host_env_vars on windows"

This reverts commit because of test failures in TestHelloWorld.

It seems that this test (specifically running "ls" as a platform

Revert "[lldb] Fix TestSettings.test_pass_host_env_vars on windows"

This reverts commit because of test failures in TestHelloWorld.

It seems that this test (specifically running "ls" as a platform shell
command) depended on the implicit passing of the host environment.

The fix should be fairly simple (inherit the environment explicitly),
but it may take me a while to figure where exactly to do that. Revert
while I am figuring that out.

show more ...

[lldb] Fix TestSettings.test_pass_host_env_vars on windows

Summary:
A defensive check in ProcessLauncherWindows meant that we would never
attempt to launch a process with a completely empty environm

[lldb] Fix TestSettings.test_pass_host_env_vars on windows

Summary:
A defensive check in ProcessLauncherWindows meant that we would never
attempt to launch a process with a completely empty environment -- the
host environment would be used instead. Instead, I make the function add
an extra null wchar_t at the end of an empty environment. The
documentation on this is a bit fuzzy, but it seems to be what is needed
to make windows accept these kinds of environments.

Reviewers: amccarth, friss

Subscribers: lldb-commits

Tags: #lldb

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

show more ...

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

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

show more ...

Fix error in ProcessLauncherWindows.cpp

Restored missing parens on a function call.

llvm-svn: 371882

Fix LLDB warnings when compiling with Clang 8.0

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

llvm-svn: 361295

Improve process launch comments for Windows

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 ove

Improve process launch comments for Windows

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

show more ...

[gdb-remote] Use lldb's portable Host::GetEnvironment() instead of getenv

Reviewers: zturner, llvm-commits, labath, serge-sans-paille

Reviewed By: labath

Subscribers: Hui, labath, lldb-commits

Di

[gdb-remote] Use lldb's portable Host::GetEnvironment() instead of getenv

Reviewers: zturner, llvm-commits, labath, serge-sans-paille

Reviewed By: labath

Subscribers: Hui, labath, lldb-commits

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

llvm-svn: 353440

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

Do not create new terminals when launching process on Windows with --no-stdio

Summary: Partially fixes PR38222

Reviewers: teemperor, zturner, stella.stamenova

Reviewed By: zturner, stella.stamenov

Do not create new terminals when launching process on Windows with --no-stdio

Summary: Partially fixes PR38222

Reviewers: teemperor, zturner, stella.stamenova

Reviewed By: zturner, stella.stamenova

Subscribers: JDevlieghere, clayborg, labath, abidh, lldb-commits

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

llvm-svn: 342075

show more ...

[lit] Split test_set_working_dir TestProcessLaunch into two tests and fix it on Windows

Summary:
test_set_working_dir was testing two scenario: failure to set the working dir because of a non existe

[lit] Split test_set_working_dir TestProcessLaunch into two tests and fix it on Windows

Summary:
test_set_working_dir was testing two scenario: failure to set the working dir because of a non existent directory and succeeding to set the working directory. Since the negative case fails on both Linux and Windows, the positive case was never tested. I split the test into two which allows us to always run both the negative and positive cases. The positive case now succeeds on Linux and the negative case still fails.
During the investigation, it turned out that lldbtest.py will try to execute a process launch command up to 3 times if the command failed. This means that we could be covering up intermittent failures by running any test that does process launch multiple times without ever realizing it. I've changed the counter to 1 (though it can still be overwritten with the environment variable).
This change also fixes both the positive and negative cases on Windows. There were a few issues:
1) In ProcessLauncherWindows::LaunchProcess, the error was not retrieved until CloseHandle was possibly called. Since CloseHandle is also a system API, its success would overwrite any existing error that could be retrieved using GetLastError. So by the time the error was retrieved, it was now a success.
2) In DebuggerThread::StopDebugging TerminateProcess was called on the process handle regardless of whether it was a valid handle. This was causing the process to crash when the handle was LLDB_INVALID_PROCESS (0xFFFFFFFF).
3) In ProcessWindows::DoLaunch we need to check that the working directory exists before launching the process to have the same behavior as other platforms which first check the directory and then launch process. This way we also control the exact error string.

Reviewers: labath, zturner, asmith, jingham

Reviewed By: labath

Subscribers: llvm-commits

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

llvm-svn: 334642

show more ...

Fix windows and freebsd builds for r322174 (Environment)

llvm-svn: 322176

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

Convert some Args index-based iteration to range-style iteration.

This is better for a number of reasons. Mostly style, but also:

1) Signed-unsigned comparison warnings disappear since there is

Convert some Args index-based iteration to range-style iteration.

This is better for a number of reasons. Mostly style, but also:

1) Signed-unsigned comparison warnings disappear since there is
no loop index.
2) Iterating with the range-for style gives you back an entry
that has more than just a const char*, so it's more efficient
and more useful.
3) Makes code safter since the type system enforces that it's
impossible to index out of bounds.

llvm-svn: 283413

show more ...

Make lldb -Werror clean on Windows.

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

llvm-svn: 283344

Change FileAction::GetPath() to return a StringRef.

llvm-svn: 282306

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

Unicode support on Win32.

Win32 API calls that are Unicode aware require wide character
strings, but LLDB uses UTF8 everywhere. This patch does conversions
wherever necessary when passing strings i

Unicode support on Win32.

Win32 API calls that are Unicode aware require wide character
strings, but LLDB uses UTF8 everywhere. This patch does conversions
wherever necessary when passing strings into and out of Win32 API
calls.

Patch by Cameron
Differential Revision: http://reviews.llvm.org/D17107
Reviewed By: zturner, amccarth

llvm-svn: 264074

show more ...

Fix TestProcessLaunch for Python 3.

There were a number of problems preventing this from working:

1. The SWIG typemaps for converting Python lists to and from C++
arrays were not updated for Pyt

Fix TestProcessLaunch for Python 3.

There were a number of problems preventing this from working:

1. The SWIG typemaps for converting Python lists to and from C++
arrays were not updated for Python 3. So they were doing things
like PyString_Check instead of using the PythonString from
PythonDataObjects.
2. ProcessLauncherWindows was ignoring the environment completely.
So any test that involved launching an inferior with any kind
of environment variable would have failed.
3. The test itself was using process.GetSTDOUT(), which isn't
implemented on Windows. So this was changed to save the
value of the environment variable in a local variable and
have the debugger look at the value of the variable.

llvm-svn: 257669

show more ...