|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3 |
|
| #
1755f5b1 |
| 19-Jan-2022 |
Jonas Devlieghere <[email protected]> |
[lldb] Decouple instrumentation from the reproducers
Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros.
Differential
[lldb] Decouple instrumentation from the reproducers
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
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc2 |
|
| #
69c55d63 |
| 10-Jan-2022 |
Jonas Devlieghere <[email protected]> |
[lldb] Remove LLDB_RECORD_CHAR_PTR_* macros
|
| #
d232abc3 |
| 10-Jan-2022 |
Jonas Devlieghere <[email protected]> |
[lldb] Remove LLDB_RECORD_RESULT macro
|
| #
d51402ac |
| 08-Jan-2022 |
Jonas Devlieghere <[email protected]> |
[lldb] Remove reproducer instrumentation
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
[lldb] Remove reproducer instrumentation
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
show more ...
|
| #
82de8df2 |
| 25-Nov-2021 |
Pavel Labath <[email protected]> |
[lldb] Clarify StructuredDataImpl ownership
StructuredDataImpl ownership semantics is unclear at best. Various structures were holding a non-owning pointer to it, with a comment that the object is o
[lldb] Clarify StructuredDataImpl ownership
StructuredDataImpl ownership semantics is unclear at best. Various structures were holding a non-owning pointer to it, with a comment that the object is owned somewhere else. From what I was able to gather that "somewhere else" was the SBStructuredData object, but I am not sure that all created object eventually made its way there. (It wouldn't matter even if they did, as we are leaking most of our SBStructuredData objects.)
Since StructuredDataImpl is just a collection of two (shared) pointers, there's really no point in elaborate lifetime management, so this patch replaces all StructuredDataImpl pointers with actual objects or unique_ptrs to it. This makes it much easier to resolve SBStructuredData leaks in a follow-up patch.
Differential Revision: https://reviews.llvm.org/D114791
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2 |
|
| #
bf9f21a2 |
| 01-Jun-2021 |
Walter Erquinigo <[email protected]> |
[trace][intel-pt] Create basic SB API
This adds a basic SB API for creating and stopping traces. Note: This doesn't add any APIs for inspecting individual instructions. That'd be a more complicated
[trace][intel-pt] Create basic SB API
This adds a basic SB API for creating and stopping traces. Note: This doesn't add any APIs for inspecting individual instructions. That'd be a more complicated change and it might be better to enhande the dump functionality to output the data in binary format. I'll leave that for a later diff.
This also enhances the existing tests so that they test the same flow using both the command interface and the SB API.
I also did some cleanup of legacy code.
Differential Revision: https://reviews.llvm.org/D103500
show more ...
|
|
Revision tags: llvmorg-12.0.1-rc1 |
|
| #
c5cf4b8f |
| 29-Apr-2021 |
Dave Lee <[email protected]> |
[lldb] Handle missing SBStructuredData copy assignment cases
Fix cases that can crash `SBStructuredData::operator=`.
This happened in a case where `rhs` had a null `SBStructuredDataImpl`.
Differen
[lldb] Handle missing SBStructuredData copy assignment cases
Fix cases that can crash `SBStructuredData::operator=`.
This happened in a case where `rhs` had a null `SBStructuredDataImpl`.
Differential Revision: https://reviews.llvm.org/D101585
show more ...
|
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1 |
|
| #
e687aa82 |
| 20-Apr-2020 |
Jonas Devlieghere <[email protected]> |
[lldb/Reproducers] Fix passive replay for (char*, size_t) functions.
Several SB API functions return strings using (char*, size_t) output arguments. During capture, we serialize an empty string for
[lldb/Reproducers] Fix passive replay for (char*, size_t) functions.
Several SB API functions return strings using (char*, size_t) output arguments. During capture, we serialize an empty string for the char* because the memory can be uninitialized.
During active replay, we have custom replay redirects that ensure that we don't override the buffer from which we're reading, but rather write to a buffer on the heap with the given length. This is sufficient for the active reproducer use case, where we only care about the side effects of the API calls, not the values actually returned.
This approach does not not work for passive replay because here we ignore all the incoming arguments, and re-execute the current function with the arguments deserialized from the reproducer. This means that these function will update the deserialized copy of the arguments, rather than whatever was passed in by the SWIG wrapper.
To solve this problem, this patch extends the reproducer instrumentation to handle this special case for passive replay. We nog ignore the replayer in the registry and the incoming char pointer, and instead reinvoke the current method on the deserialized class, and populate the output argument.
Differential revision: https://reviews.llvm.org/D77759
show more ...
|
|
Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3 |
|
| #
866b7a65 |
| 18-Feb-2020 |
Jonas Devlieghere <[email protected]> |
[lldb] Replace empty ctor en dtor bodies with =default (NFC)
Use = default instead of empty constructor and destructor bodies in the API layer.
|
|
Revision tags: llvmorg-10.0.0-rc2 |
|
| #
3da7dcf3 |
| 06-Feb-2020 |
Jonas Devlieghere <[email protected]> |
[lldb/Reproducers] Serialize empty string for char* methods.
For the methods taking a char* and a length that have a custom replayer, ignore the incoming string in the instrumentation macro. This pr
[lldb/Reproducers] Serialize empty string for char* methods.
For the methods taking a char* and a length that have a custom replayer, ignore the incoming string in the instrumentation macro. This prevents potentially reading garbage and blowing up the SB API log.
show more ...
|
| #
2f025bb8 |
| 06-Feb-2020 |
Jonas Devlieghere <[email protected]> |
[lldb/Reproducers] Implement custom replayers for (char *, size_t)
Some SB API methods returns strings through a char* and a length. This is a problem for the deserializer, which considers a single
[lldb/Reproducers] Implement custom replayers for (char *, size_t)
Some SB API methods returns strings through a char* and a length. This is a problem for the deserializer, which considers a single type at a time, and therefore cannot know how many bytes to allocate for the character buffer.
We can solve this problem by implementing a custom replayer, which ignores the passed-in char* and allocates a buffer of the correct size itself, before invoking the original API method or function.
This patch adds three new macros to register a custom replayer for methods that take a char* and a size_t. It supports arbitrary return values (some functions return a bool while others return a size_t).
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc1 |
|
| #
80814287 |
| 24-Jan-2020 |
Raphael Isemann <[email protected]> |
[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 ...
|
|
Revision tags: llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1 |
|
| #
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 ...
|
|
Revision tags: llvmorg-8.0.0-rc4 |
|
| #
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 ...
|
|
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 ...
|
| #
181b823b |
| 14-Dec-2018 |
Pavel Labath <[email protected]> |
Move Broadcaster+Listener+Event combo from Core into Utility
Summary: These are general purpose "utility" classes, whose functionality is not debugger-specific in any way. As such, I believe they be
Move Broadcaster+Listener+Event combo from Core into Utility
Summary: These are general purpose "utility" classes, whose functionality is not debugger-specific in any way. As such, I believe they belong in the Utility module.
This doesn't break any particular dependency (yet), but it reduces the number of Core dependencies across the board.
Reviewers: zturner, jingham, teemperor, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D55361
llvm-svn: 349157
show more ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0 |
|
| #
3815e702 |
| 13-Sep-2018 |
Jim Ingham <[email protected]> |
Add a "scripted" breakpoint type to lldb.
This change allows you to write a new breakpoint type where the logic for setting breakpoints is determined by a Python callback written using the SB API's.
Add a "scripted" breakpoint type to lldb.
This change allows you to write a new breakpoint type where the logic for setting breakpoints is determined by a Python callback written using the SB API's.
Differential Revision: https://reviews.llvm.org/D51830
llvm-svn: 342185
show more ...
|
|
Revision tags: llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, 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, 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, llvmorg-5.0.0-rc1 |
|
| #
f2a8bccf |
| 27-Jun-2017 |
Pavel Labath <[email protected]> |
Move StructuredData from Core to Utility
Summary: It had a dependency on StringConvert and file reading code, which is not in Utility. I've replaced that code by equivalent llvm operations.
I've ad
Move StructuredData from Core to Utility
Summary: It had a dependency on StringConvert and file reading code, which is not in Utility. I've replaced that code by equivalent llvm operations.
I've added a unit test to demonstrate that parsing a file still works.
Reviewers: zturner, jingham
Subscribers: kubamracek, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34625
llvm-svn: 306394
show more ...
|
|
Revision tags: llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2 |
|
| #
5bfee5f1 |
| 29-May-2017 |
Abhishek Aggarwal <[email protected]> |
Added new API to SBStructuredData class
Summary: - Added API to access data types -- integer, double, array, string, boolean and dictionary data types -- Earlier user had to parse through t
Added new API to SBStructuredData class
Summary: - Added API to access data types -- integer, double, array, string, boolean and dictionary data types -- Earlier user had to parse through the string output to get these values
- Added Test cases for API testing
- Added new StructuredDataType enum in public include file -- Replaced locally-defined enum in StructuredData.h with this new one -- Modified other internal files using this locally-defined enum
Signed-off-by: Abhishek Aggarwal <[email protected]>
Reviewers: clayborg, lldb-commits
Reviewed By: clayborg
Subscribers: labath
Differential Revision: https://reviews.llvm.org/D33434
llvm-svn: 304138
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 ...
|
|
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, 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 |
|
| #
2ef442c6 |
| 09-Nov-2016 |
Todd Fiala <[email protected]> |
Fix weak symbol linkage in SBStructuredData, update docs.
Summary: This change fixes an issue where I was leaking a weakly-linked symbol in the SBAPI. It also updates the docs to call out what I did
Fix weak symbol linkage in SBStructuredData, update docs.
Summary: This change fixes an issue where I was leaking a weakly-linked symbol in the SBAPI. It also updates the docs to call out what I did wrong.
Fixes: rdar://28882483
Reviewers: jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D26470
llvm-svn: 286413
show more ...
|