| Age | Commit message (Collapse) | Author |
|---|
|
It's not used since https://reviews.llvm.org/D157556.
|
|
LLDB should guarantee that the strings returned by SBAPI methods
live forever. I went through every method that returns a string and made
sure that it was added to the ConstString StringPool before returning if
it wasn't obvious that it was already doing so.
I've also updated the docs to document this behavior.
Differential Revision: https://reviews.llvm.org/D150804
|
|
This patch augments lldb's event listeners with a new shadow mode.
As the name suggests, this mode allows events to be copied to an
additional listener to perform event monitoring, without interferring
with the event life cycle.
One of our use case for this, is to be able to listen to public process
events while making sure the events will still be delivered to the
default process listener (the debugger listener in most cases).
Differential Revision: https://reviews.llvm.org/D148397
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This patch moves `ScriptedMetadata.h` from the `Interpreter` directory to
the `Utility` sub-directory since `ProcessInfo.h` depends on it.
It also gets rid of the unused `OptionGroupPythonClassWithDict`
constructor for `ScriptedMetadata` which would address the layering
violation.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This patch adds process attach capabilities to the ScriptedProcess
plugin. This doesn't really expects a PID or process name, since the
process state is already script, however, this allows to create a
scripted process without requiring to have an executuble in the target.
In order to do so, this patch also turns the scripted process related
getters and setters from the `ProcessLaunchInfo` and
`ProcessAttachInfo` classes to a `ScriptedMetadata` instance and moves
it in the `ProcessInfo` class, so it can be accessed interchangeably.
This also adds the necessary SWIG wrappers to convert the internal
`Process{Attach,Launch}InfoSP` into a `SB{Attach,Launch}Info` to pass it
as argument the scripted process python implementation and convert it
back to the internal representation.
rdar://104577406
Differential Revision: https://reviews.llvm.org/D143104
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
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
|
|
adding caching of resolved/absolute." and follow-ups
This reverts commit 9429b67b8e300e638d7828bbcb95585f85c4df4d.
It broke the build on Windows, see comments on https://reviews.llvm.org/D130309
It also reverts these follow-ups:
Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309."
This reverts commit f959d815f4637890ebbacca379f1c38ab47e4e14.
Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309."
This reverts commit 0bbce7a4c2d2bff622bdadd4323f93f5d90e6d24.
Revert "Cache the value for absolute path in FileSpec."
This reverts commit dabe877248b85b34878e75d5510339325ee087d0.
|
|
caching of resolved/absolute.
The FileSpect APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossibly to control all of the times the FileSpec object is modified so we can clear the cache. This patch modifies the APIs of FileSpec so no one can modify the directory or filename 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/D130309
|
|
Remove the last remaining references to the reproducers from the
instrumentation. This patch renames the relevant files and macros.
Differential revision: https://reviews.llvm.org/D117712
|
|
|
|
This patch removes most of the reproducer instrumentation. It keeps
around the LLDB_RECORD_* macros for logging. See [1] for more details.
[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html
Differential revision: https://reviews.llvm.org/D116847
|
|
Identified with readability-redundant-member-init.
|
|
This patch adds a new `StructuredData::Dictionary` constructor that
takes a `StructuredData::ObjectSP` as an argument. This is used to pass
the opaque_ptr from the `SBStructuredData` used to initialize a
ScriptedProecss, to the `ProcessLaunchInfo` class.
This also updates `SBLaunchInfo::SetScriptedProcessDictionary` to
reflect the formentionned changes which solves the nullptr deref.
Differential Revision: https://reviews.llvm.org/D112107
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This patch adds a new command options to the CommandObjectProcessLaunch
for scripted processes.
Among the options, the user need to specify the class name managing the
scripted process. The user can also use a key-value dictionary holding
arbitrary data that will be passed to the managing class.
This patch also adds getters and setters to `SBLaunchInfo` for the
class name managing the scripted process and the dictionary.
rdar://65508855
Differential Review: https://reviews.llvm.org/D95710
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This patch reverts the following commits:
- 5a9c34918bb1526b7e8c29aa5e4fb8d8e27e27b4
- 46796762afe76496ec4dd900f64d0cf4cdc30e99
- 2cff3dec1171188ce04ab1a4373cc1885ab97be1
- 182f0d1a34419445bb19d67581d6ac1afc98b7fa
- d62a53aaf1d38a55d1affbd3a30d564a4e9d3171
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This patch adds a new command options to the CommandObjectProcessLaunch
for scripted processes.
Among the options, the user need to specify the class name managing the
scripted process. The user can also use a key-value dictionary holding
arbitrary data that will be passed to the managing class.
This patch also adds getters and setters to `SBLaunchInfo` for the
class name managing the scripted process and the dictionary.
rdar://65508855
Differential Review: https://reviews.llvm.org/D95710
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
SBLaunchInfo::SetEnvironment(append=true)"
The patch was reverted 27d52cd86a2c because of failures in
TestWeakSymbols.py. These have now been addressed in D83552.
The original commit message was:
This function was documented to overwrite entries with D76111, which was
adding a couple of similar functions. However, this function (unlike the
functions added in that patch) was/is not actually overwriting variables
-- any pre-existing variables would get ignored.
This behavior does not seem to be intentional. In fact, before the refactor in
D41359, this function could introduce duplicate entries, which could
have very surprising effects both inside lldb and on other applications
(some applications would take the first value, some the second one; in
lldb, attempting to unset a variable could make the second variable
become active, etc.).
Overwriting seems to be the most reasonable behavior here, so change the
code to match documentation.
Differential Revision: https://reviews.llvm.org/D83306
|
|
SBLaunchInfo::SetEnvironment(append=true)"
This reverts commit 695b33a56919af8873eecb47cb83fa17a271e99f beacuse
it broke the macOS bot.
|
|
Summary:
This function was documented to overwrite entries with D76111, which was
adding a couple of similar functions. However, this function (unlike the
functions added in that patch) was/is not actually overwriting variables
-- any pre-existing variables would get ignored.
This behavior does not seem to be intentional. In fact, before the refactor in
D41359, this function could introduce duplicate entries, which could
have very surprising effects both inside lldb and on other applications
(some applications would take the first value, some the second one; in
lldb, attempting to unset a variable could make the second variable
become active, etc.).
Overwriting seems to be the most reasonable behavior here, so change the
code to match documentation.
Reviewers: clayborg, wallace, jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D83306
|
|
|
|
This reverts commit fd868f517d2c5ca8c0f160dbec0857b14ecf74c1.
|
|
|
|
This reverts commit 34c0759f846447454714c8faa0e1753a8713637b.
|
|
Summary: Inspired by https://reviews.llvm.org/D74636, I'm introducing a basic version of Environment in the API. More functionalities can be added as needed.
Reviewers: labath, clayborg
Subscribers: mgorny, lldb-commits, diazhector98
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76111
|
|
while investigating bot breakage.
This reverts commit 2dec82652e4b6424e46e7bd674cb6404e01e218e.
|
|
Summary: Inspired by https://reviews.llvm.org/D74636, I'm introducing a basic version of Environment in the API. More functionalities can be added as needed.
Reviewers: labath, clayborg
Subscribers: mgorny, lldb-commits, diazhector98
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76111
|
|
Use = default instead of empty constructor and destructor bodies in the
API layer.
|
|
The copy assignment operator is supposed to return the class and not
void. Fix the methods and the reproducer instrumentation macros.
|
|
Currently the constructor is compiler generated which means it doesn't
get instrumented for the reproducers.
|
|
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
|
|
Move SBRegistry method registrations from SBReproducer.cpp into files
declaring the individual APIs, in order to reduce the memory consumption
during build and improve maintainability. The current humongous
SBRegistry constructor exhausts all memory on a NetBSD system with 4G
RAM + 4G swap, therefore making it impossible to build LLDB.
Differential Revision: https://reviews.llvm.org/D59427
llvm-svn: 356481
|
|
This patch adds the SBReproducer macros needed to capture and reply the
corresponding calls. This patch was generated by running the lldb-instr
tool on the API source files.
Differential revision: https://reviews.llvm.org/D57475
llvm-svn: 355459
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Summary:
There was some confusion in the code about how to represent process
environment. Most of the code (ab)used the Args class for this purpose,
but some of it used a more basic StringList class instead. In either
case, the fact that the underlying abstraction did not provide primitive
operations for the typical environment operations meant that even a
simple operation like checking for an environment variable value was
several lines of code.
This patch adds a separate Environment class, which is essentialy a
llvm::StringMap<std::string> in disguise. To standard StringMap
functionality, it adds a couple of new functions, which are specific to
the environment use case:
- (most important) envp conversion for passing into execve() and likes.
Instead of trying to maintain a constantly up-to-date envp view, it
provides a function which creates a envp view on demand, with the
expectation that this will be called as the very last thing before
handing the value to the system function.
- insert(StringRef KeyEqValue) - splits KeyEqValue into (key, value)
pair and inserts it into the environment map.
- compose(value_type KeyValue) - takes a map entry and converts in back
into "KEY=VALUE" representation.
With this interface most of the environment-manipulating code becomes
one-liners. The only tricky part was maintaining compatibility in
SBLaunchInfo, which expects that the environment entries are accessible
by index and that the returned const char* is backed by the launch info
object (random access into maps is hard and the map stores the entry in
a deconstructed form, so we cannot just return a .c_str() value). To
solve this, I have the SBLaunchInfo convert the environment into the
"envp" form, and use it to answer the environment queries. Extra code is
added to make sure the envp version is always in sync.
(This also improves the layering situation as Args was in the Interpreter module
whereas Environment is in Utility.)
Reviewers: zturner, davide, jingham, clayborg
Subscribers: emaste, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D41359
llvm-svn: 322174
|
|
*** 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
|
|
Summary:
This should solve the issue of sending denormalized paths over gdb-remote
if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the
server handle any denormalization.
Reviewers: ovyalov, zturner, vharron, clayborg
Reviewed By: clayborg
Subscribers: tberghammer, emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D9728
llvm-svn: 238604
|
|
Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore, all includes of it should be localized to
the python library which will live under source/bindings/API/Python
after a future patch.
None of the files that were including this header actually depended
on it anyway, so it was just a dead include in every single instance.
llvm-svn: 238581
|
|
This should not bring any feature change, except changing names of things here and there
llvm-svn: 230077
|
|
Summary:
This patch adds -exec-arguments command for lldb-mi. -exec-arguments command allows to specify arguments for executable file in MI mode. Also it contains tests for that command.
Btw, new added files was formatted by clang-format.
Reviewers: abidh, zturner, clayborg
Reviewed By: clayborg
Subscribers: zturner, emaste, clayborg, jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D6965
llvm-svn: 229110
|
|
llvm-svn: 228660
|
|
Integrate this change into test framework in order to spawn processes on a remote target.
http://reviews.llvm.org/D7263
llvm-svn: 228230
|
