|
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, llvmorg-13.0.1-rc2, 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 |
|
| #
76e47d48 |
| 26-May-2021 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivale
[lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivalent.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D103084
show more ...
|
|
Revision tags: llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3 |
|
| #
3dcbfa27 |
| 04-Mar-2021 |
Jonas Devlieghere <[email protected]> |
[debugserver] Fix more compiler warnings on arm64
This fixes the following two warnings in code that's only compiled on arm64:
- warning: cast from 'const void *' to 'unsigned char *' drops const
[debugserver] Fix more compiler warnings on arm64
This fixes the following two warnings in code that's only compiled on arm64:
- warning: cast from 'const void *' to 'unsigned char *' drops const qualifier [-Wcast-qual] - warning: embedding a directive within macro arguments has undefined behavior [-Wembedded-directive]
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3 |
|
| #
39047f6c |
| 02-Feb-2021 |
Jonas Devlieghere <[email protected]> |
[debugserver] Fix -Wmissing-field-initializers warnings on arm64
|
| #
ec6815a7 |
| 02-Feb-2021 |
Jonas Devlieghere <[email protected]> |
[debugserver] Fix -Wsign-compare warnings on arm64
|
| #
9a62b724 |
| 02-Feb-2021 |
Jonas Devlieghere <[email protected]> |
[debugserver] Fix -Wunused-function warnings on arm64
|
|
Revision tags: 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, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1 |
|
| #
96f3ea0d |
| 24-Jan-2020 |
Jonas Devlieghere <[email protected]> |
[lldb/debugserver] Implement hardware breakpoints for x86_64 and i386
This implements hardware breakpoints for x86_64 and i386 in debugserver. It's based on Pedro's patch sent to lldb-commits [1] al
[lldb/debugserver] Implement hardware breakpoints for x86_64 and i386
This implements hardware breakpoints for x86_64 and i386 in debugserver. It's based on Pedro's patch sent to lldb-commits [1] although most of it is the same as the existing hardware watchpoint implementation.
[1] http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20200113/060327.html
Differential revision: https://reviews.llvm.org/D72985
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 |
|
| #
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 ...
|
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, 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 ...
|
|
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, 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, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2 |
|
| #
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, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, 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 ...
|
|
Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, llvmorg-3.8.1, llvmorg-3.8.1-rc1, llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1 |
|
| #
9878e3b4 |
| 15-Sep-2015 |
Jason Molenda <[email protected]> |
A partner to the cleanup in r247741, change the variables names in debugserver to match. "gcc" is now "ehframe" and "gdb" is now "debugserver". Because this is debugserver, what we call the Process
A partner to the cleanup in r247741, change the variables names in debugserver to match. "gcc" is now "ehframe" and "gdb" is now "debugserver". Because this is debugserver, what we call the Process Plugin register numbers up in lldb are the debugserver register numbers down here - they are the register numbers that debugserver will use to refer to these registers over the gdb-remote protocol.
debugserver was already reporting the registers with the key "ehframe"; this change is just cleaning up the internal variable names to match.
llvm-svn: 247751
show more ...
|
|
Revision tags: llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3, llvmorg-3.7.0-rc2 |
|
| #
8a67bf72 |
| 24-Jul-2015 |
Bruce Mitchener <[email protected]> |
Add UNUSED_IF_ASSERT_DISABLED and apply it.
Summary: This replaces (void)x; usages where they x was subsequently involved in an assertion with this macro to make the intent more clear.
Reviewers: c
Add UNUSED_IF_ASSERT_DISABLED and apply it.
Summary: This replaces (void)x; usages where they x was subsequently involved in an assertion with this macro to make the intent more clear.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11451
llvm-svn: 243074
show more ...
|
| #
a026de05 |
| 22-Jul-2015 |
Bruce Mitchener <[email protected]> |
Fix warnings.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11404
llvm-svn: 242913
|
|
Revision tags: llvmorg-3.7.0-rc1, llvmorg-3.6.2, llvmorg-3.6.2-rc1, llvmorg-3.6.1, llvmorg-3.6.1-rc1, llvmorg-3.5.2, llvmorg-3.5.2-rc1 |
|
| #
ee2ed525 |
| 09-Mar-2015 |
Greg Clayton <[email protected]> |
Fix debugserver warnings on MacOSX.
llvm-svn: 231692
|
|
Revision tags: llvmorg-3.6.0, llvmorg-3.6.0-rc4, llvmorg-3.6.0-rc3, llvmorg-3.6.0-rc2 |
|
| #
35c99871 |
| 16-Jan-2015 |
Jason Molenda <[email protected]> |
Add comments explaining the unwind setup in ABIMacOSX_i386::CreateFunctionEntryUnwindPlan, ABIMacOSX_i386::CreateDefaultUnwindPlan, ABISysV_x86_64::CreateFunctionEntryUnwindPlan, ABISysV_x86_64::Cre
Add comments explaining the unwind setup in ABIMacOSX_i386::CreateFunctionEntryUnwindPlan, ABIMacOSX_i386::CreateDefaultUnwindPlan, ABISysV_x86_64::CreateFunctionEntryUnwindPlan, ABISysV_x86_64::CreateDefaultUnwindPlan
llvm-svn: 226347
show more ...
|
| #
bcc57859 |
| 16-Jan-2015 |
Jason Molenda <[email protected]> |
Fixes to DNBArchImpl in debugserver to correctly get/set the register state when debugging AArch32 programs (armv7 programs running on an armv8 processor). Most notably, there is no "fpscr" register
Fixes to DNBArchImpl in debugserver to correctly get/set the register state when debugging AArch32 programs (armv7 programs running on an armv8 processor). Most notably, there is no "fpscr" register in the register context - there is an fpsr and an fpcr.
Also fix a bug where the floating point values could not be written in armv7 processes. <rdar://problem/18977767>
llvm-svn: 226244
show more ...
|
|
Revision tags: llvmorg-3.6.0-rc1, llvmorg-3.5.1, llvmorg-3.5.1-rc2 |
|
| #
a97c4d21 |
| 09-Dec-2014 |
Greg Clayton <[email protected]> |
Handle thumb IT instructions correctly all the time.
The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint
Handle thumb IT instructions correctly all the time.
The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true.
When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction.
The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match.
To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed.
This patch does the following: 1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb 2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute 3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb 4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below)
This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added.
<rdar://problem/19145455>
llvm-svn: 223851
show more ...
|
|
Revision tags: llvmorg-3.5.1-rc1, llvmorg-3.5.0, llvmorg-3.5.0-rc4, llvmorg-3.5.0-rc3, llvmorg-3.5.0-rc2, llvmorg-3.5.0-rc1 |
|
| #
013434e5 |
| 09-Jul-2014 |
Todd Fiala <[email protected]> |
__arm64__ and __aarch64__ #ifdef adjustments
Change by Paul Osmialowski
See http://reviews.llvm.org/D4379 for details.
llvm-svn: 212583
|
| #
aaa0ba31 |
| 08-Jul-2014 |
Bruce Mitchener <[email protected]> |
Fix typos.
llvm-svn: 212553
|
| #
c1fdb889 |
| 27-Jun-2014 |
Jim Ingham <[email protected]> |
Revert the debugserver part of r211868. While formally a fine change, debugserver doesn't depend on llvm (it really doesn't even depend on anything in lldb) and this nicety isn't worth adding that d
Revert the debugserver part of r211868. While formally a fine change, debugserver doesn't depend on llvm (it really doesn't even depend on anything in lldb) and this nicety isn't worth adding that dependence.
llvm-svn: 211903
show more ...
|
| #
28606954 |
| 27-Jun-2014 |
Saleem Abdulrasool <[email protected]> |
lldb: remove adhoc implementation of array_sizeof
Replace adhoc inline implementation of llvm::array_lengthof in favour of the implementation in LLVM. This is simply a cleanup change, no functional
lldb: remove adhoc implementation of array_sizeof
Replace adhoc inline implementation of llvm::array_lengthof in favour of the implementation in LLVM. This is simply a cleanup change, no functional change intended.
llvm-svn: 211868
show more ...
|
|
Revision tags: llvmorg-3.4.2, llvmorg-3.4.2-rc1 |
|
| #
f0d5b540 |
| 30-Apr-2014 |
Jason Molenda <[email protected]> |
Correct offsets in the debugserver arm back end for the s and d registers so we get the offsets of these correct after the changes of r194302. <rdar://problem/16176270>
llvm-svn: 207600
|
|
Revision tags: llvmorg-3.4.1, llvmorg-3.4.1-rc2, llvmorg-3.4.1-rc1 |
|
| #
a332978b |
| 29-Mar-2014 |
Jason Molenda <[email protected]> |
lldb arm64 import.
These changes were written by Greg Clayton, Jim Ingham, Jason Molenda.
It builds cleanly against TOT llvm with xcodebuild. I updated the cmake files by visual inspection but did
lldb arm64 import.
These changes were written by Greg Clayton, Jim Ingham, Jason Molenda.
It builds cleanly against TOT llvm with xcodebuild. I updated the cmake files by visual inspection but did not try a build. I haven't built these sources on any non-Mac platforms - I don't think this patch adds any code that requires darwin, but please let me know if I missed something.
In debugserver, MachProcess.cpp and MachTask.cpp were renamed to MachProcess.mm and MachTask.mm as they picked up some new Objective-C code needed to launch processes when running on iOS.
llvm-svn: 205113
show more ...
|
|
Revision tags: llvmorg-3.4.0, llvmorg-3.4.0-rc3, llvmorg-3.4.0-rc2 |
|
| #
db2f51e5 |
| 21-Nov-2013 |
Jason Molenda <[email protected]> |
Fixes to get the arm native debugserver building again. Fix a small typeo in the i386/x86_64 debugserver plugins.
llvm-svn: 195308
|
|
Revision tags: llvmorg-3.4.0-rc1 |
|
| #
f74cf86b |
| 13-Nov-2013 |
Greg Clayton <[email protected]> |
<rdar://problem/15172417>
Added two new GDB server packets to debugserver: "QSaveRegisterState" and "QRestoreRegiterState".
"QSaveRegisterState" makes the remote GDB server save all register values
<rdar://problem/15172417>
Added two new GDB server packets to debugserver: "QSaveRegisterState" and "QRestoreRegiterState".
"QSaveRegisterState" makes the remote GDB server save all register values and it returns a save identifier as an unsigned integer. This packet can be used prior to running expressions to save all registers.
All registers can them we later restored with "QRestoreRegiterState:SAVEID" what SAVEID is the integer identifier that was returned from the call to QSaveRegisterState.
Cleaned up redundant code in lldb_private::Thread, lldb_private::ThreadPlanCallFunction. Moved the lldb_private::Thread::RegisterCheckpoint into its own header file and it is now in the lldb_private namespace. Trimmed down the RegisterCheckpoint class to omit stuff that wasn't used (the stack ID).
Added a few new virtual methods to lldb_private::RegisterContext that allow subclasses to efficiently save/restore register states and changed the RegisterContextGDBRemote to take advantage of these new calls.
llvm-svn: 194621
show more ...
|