|
Revision tags: llvmorg-8.0.1-rc1 |
|
| #
8b3af63b |
| 10-Apr-2019 |
Jonas Devlieghere <[email protected]> |
[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 ...
|
| #
306809f2 |
| 03-Apr-2019 |
Jonas Devlieghere <[email protected]> |
[Reproducers] Capture return values of functions returning by ptr/ref
For some reason I had convinced myself that functions returning by pointer or reference do not require recording their result. H
[Reproducers] Capture return values of functions returning by ptr/ref
For some reason I had convinced myself that functions returning by pointer or reference do not require recording their result. However, after further considering I don't see how that could work, at least not with the current implementation. Interestingly enough, the reproducer instrumentation already (mostly) accounts for this, though the lldb-instr tool did not.
This patch adds the missing macros and updates the lldb-instr tool.
Differential revision: https://reviews.llvm.org/D60178
llvm-svn: 357639
show more ...
|
| #
ae211ece |
| 19-Mar-2019 |
Michal Gorny <[email protected]> |
[lldb] [Reproducer] Move SBRegistry registration into declaring files
Move SBRegistry method registrations from SBReproducer.cpp into files declaring the individual APIs, in order to reduce the memo
[lldb] [Reproducer] Move SBRegistry registration into declaring files
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
show more ...
|
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5 |
|
| #
7f5237bc |
| 11-Mar-2019 |
Pavel Labath <[email protected]> |
Add "operator bool" to SB APIs
Summary: Our python version of the SB API has (the python equivalent of) operator bool, but the C++ version doesn't.
This is because our python operators are added by
Add "operator bool" to SB APIs
Summary: Our python version of the SB API has (the python equivalent of) operator bool, but the C++ version doesn't.
This is because our python operators are added by modify-python-lldb.py, which performs postprocessing on the swig-generated interface files.
In this patch, I add the "operator bool" to all SB classes which have an IsValid method (which is the same logic used by modify-python-lldb.py). This way, we make the two interfaces more constent, and it allows us to rely on swig's automatic syntesis of python __nonzero__ methods instead of doing manual fixups.
Reviewers: zturner, jingham, clayborg, jfb, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58792
llvm-svn: 355824
show more ...
|
| #
0d7b0c96 |
| 08-Mar-2019 |
Jonas Devlieghere <[email protected]> |
[Reproducers] Add missing LLDB_RECORD_DUMMY macros
Re-ran lldb-inst on the API folder to insert missing LLDB_RECORD_DUMMY macros.
llvm-svn: 355711
|
|
Revision tags: llvmorg-8.0.0-rc4 |
|
| #
581af8b0 |
| 07-Mar-2019 |
Jonas Devlieghere <[email protected]> |
[SBAPI] Log from record macro
The current record macros already log the function being called. This patch extends the macros to also log their input arguments and removes explicit logging from the S
[SBAPI] Log from record macro
The current record macros already log the function being called. This patch extends the macros to also log their input arguments and removes explicit logging from the SB API.
This might degrade the amount of information in some cases (because of smarter casts or efforts to log return values). However I think this is outweighed by the increased coverage and consistency. Furthermore, using the reproducer infrastructure, diagnosing bugs in the API layer should become much easier compared to relying on log messages.
Differential revision: https://reviews.llvm.org/D59101
llvm-svn: 355649
show more ...
|
| #
baf5664f |
| 06-Mar-2019 |
Jonas Devlieghere <[email protected]> |
[Reproducers] Add SBReproducer macros
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
[Reproducers] Add SBReproducer macros
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
show more ...
|
| #
805e7106 |
| 04-Mar-2019 |
Zachary Turner <[email protected]> |
Move ProcessInfo from Host to Utility.
There are set of classes in Target that describe the parameters of a process - e.g. it's PID, name, user id, and similar. However, since it is a bare descripti
Move ProcessInfo from Host to Utility.
There are set of classes in Target that describe the parameters of a process - e.g. it's PID, name, user id, and similar. However, since it is a bare description of a process and contains no actual functionality, there's nothing specifically that makes this appropriate for being in Target -- it could just as well be describing a process on the host, or some hypothetical virtual process that doesn't even exist.
To cement this, I'm moving these classes to Utility. It's possible that we can find a better place for it in the future, but as it is neither Host specific nor Target specific, Utility seems like the most appropriate place for the time being.
After this there is only 2 remaining references to Target from Host, which I'll address in a followup.
Differential Revision: https://reviews.llvm.org/D58842
llvm-svn: 355342
show more ...
|
|
Revision tags: llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
| #
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <[email protected]> |
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 ...
|
| #
36788bbb |
| 20-Dec-2018 |
Tatyana Krasnukha <[email protected]> |
Replace MemoryRegionInfoSP with values and cleanup related code
Differential Revision: https://reviews.llvm.org/D55472
llvm-svn: 349766
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3 |
|
| #
ceff6644 |
| 11-Nov-2018 |
Jonas Devlieghere <[email protected]> |
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 ...
|
|
Revision tags: llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1 |
|
| #
8f3be7a3 |
| 01-Nov-2018 |
Jonas Devlieghere <[email protected]> |
[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 ...
|
|
Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2 |
|
| #
d821c997 |
| 07-Aug-2018 |
Pavel Labath <[email protected]> |
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 ...
|
|
Revision tags: llvmorg-7.0.0-rc1 |
|
| #
0d231f71 |
| 28-Jun-2018 |
Jim Ingham <[email protected]> |
Add a way to load an image using a library name and list of paths.
This provides an efficient (at least on Posix platforms) way to offload to the target process the search & loading of a library whe
Add a way to load an image using a library name and list of paths.
This provides an efficient (at least on Posix platforms) way to offload to the target process the search & loading of a library when all we have are the library name and a set of potential candidate locations.
<rdar://problem/40905971>
llvm-svn: 335912
show more ...
|
|
Revision tags: llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2 |
|
| #
05097246 |
| 30-Apr-2018 |
Adrian Prantl <[email protected]> |
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 ...
|
|
Revision tags: llvmorg-6.0.1-rc1 |
|
| #
145d95c9 |
| 17-Apr-2018 |
Pavel Labath <[email protected]> |
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 ...
|
|
Revision tags: llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1 |
|
| #
62930e57 |
| 10-Jan-2018 |
Pavel Labath <[email protected]> |
Add Utility/Environment class for handling... environments
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
Add Utility/Environment class for handling... environments
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
show more ...
|
|
Revision tags: llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2 |
|
| #
141a6263 |
| 01-Aug-2017 |
Vadim Macagon <[email protected]> |
Expose process instance info via SB API
Summary: Implement SBProcessInfo to wrap lldb_private::ProcessInstanceInfo, and add SBProcess::GetProcessInfo() to retrieve info like parent ID, group ID, use
Expose process instance info via SB API
Summary: Implement SBProcessInfo to wrap lldb_private::ProcessInstanceInfo, and add SBProcess::GetProcessInfo() to retrieve info like parent ID, group ID, user ID etc. from a live process.
Differential Revision: https://reviews.llvm.org/D35881
llvm-svn: 309664
show more ...
|
|
Revision tags: llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2 |
|
| #
e714c4f5 |
| 26-May-2017 |
Ravitheja Addepally <[email protected]> |
Implementation of remote packets for Trace data.
Summary: The changes consist of new packets for trace manipulation and trace collection. The new packets are also documented. The packets are capable
Implementation of remote packets for Trace data.
Summary: The changes consist of new packets for trace manipulation and trace collection. The new packets are also documented. The packets are capable of providing custom trace specific parameters to start tracing and also retrieve such configuration from the server.
Reviewers: clayborg, lldb-commits, tberghammer, labath, zturner
Reviewed By: clayborg, labath
Subscribers: krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D32585
llvm-svn: 303972
show more ...
|
| #
97206d57 |
| 12-May-2017 |
Zachary Turner <[email protected]> |
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 ...
|
| #
abc5d72f |
| 06-May-2017 |
Jim Ingham <[email protected]> |
Be a little more permissive in DynamicLoaderMacOS::CanLoadImage
If we can't find the "is dyld locked" symbol, assume it is safe to load the image unless we only have 1 image loaded - in which case w
Be a little more permissive in DynamicLoaderMacOS::CanLoadImage
If we can't find the "is dyld locked" symbol, assume it is safe to load the image unless we only have 1 image loaded - in which case we are in _dyld_start and it is definitely NOT safe.
Also add a little better errors to that function, and better logging in SBProcess.cpp.
<rdar://problem/30174817>
llvm-svn: 302327
show more ...
|
|
Revision tags: llvmorg-4.0.1-rc1 |
|
| #
d5d8d91c |
| 26-Apr-2017 |
Ravitheja Addepally <[email protected]> |
Initial implementation of SB APIs for Tracing support.
Summary: This patch introduces new SB APIs for tracing support inside LLDB. The idea is to gather trace data from LLDB and provide it through t
Initial implementation of SB APIs for Tracing support.
Summary: This patch introduces new SB APIs for tracing support inside LLDB. The idea is to gather trace data from LLDB and provide it through this APIs to external tools integrating with LLDB. These tools will be responsible for interpreting and presenting the trace data to their users.
The patch implements the following new SB APIs -> -> StartTrace - starts tracing with given parameters -> StopTrace - stops tracing. -> GetTraceData - read the trace data . -> GetMetaData - read the meta data assosciated with the trace. -> GetTraceConfig - read the trace configuration
Tracing is associated with a user_id that is returned by the StartTrace API and this id needs to be used for accessing the trace data and also Stopping the trace. The user_id itself may map to tracing the complete process or just an individual thread. The APIs require an additional thread parameter when the user of these APIs wishes to perform thread specific manipulations on the tracing instances. The patch also includes the corresponding python wrappers for the C++ based APIs.
Reviewers: k8stone, lldb-commits, clayborg
Reviewed By: clayborg
Subscribers: jingham, mgorny
Differential Revision: https://reviews.llvm.org/D29581
llvm-svn: 301389
show more ...
|
|
Revision tags: llvmorg-4.0.0, llvmorg-4.0.0-rc4 |
|
| #
6f9e6901 |
| 03-Mar-2017 |
Zachary Turner <[email protected]> |
Move Log from Core -> Utility.
All references to Host and Core have been removed, so this class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-
Move Log from Core -> Utility.
All references to Host and Core have been removed, so this class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
show more ...
|
|
Revision tags: llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2 |
|
| #
bf9a7730 |
| 02-Feb-2017 |
Zachary Turner <[email protected]> |
Move classes from Core -> Utility.
This moves the following classes from Core -> Utility.
ConstString Error RegularExpression Stream StreamString
The goal here is to get lldbUtility into a state w
Move classes from Core -> Utility.
This moves the following classes from Core -> Utility.
ConstString Error RegularExpression Stream StreamString
The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
show more ...
|
|
Revision tags: llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1 |
|
| #
b9c1b51e |
| 06-Sep-2016 |
Kate Stone <[email protected]> |
*** 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 ...
|