History log of /llvm-project-15.0.7/lldb/source/Target/ABI.cpp (Results 1 – 25 of 48)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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
# c34698a8 03-Feb-2022 Pavel Labath <[email protected]>

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
inf

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.

After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.

show more ...


Revision tags: llvmorg-15-init
# a007a6d8 31-Jan-2022 Pavel Labath <[email protected]>

[lldb] Convert "LLDB" log channel to the new API


Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1
# 58492191 05-Oct-2021 Michał Górny <[email protected]>

[lldb] [ABI] Apply AugmentRegisterInfo() to DynamicRegisterInfo::Registers

Call ABI::AugmentRegisterInfo() once with a vector of all defined
registers rather than calling it for every individual reg

[lldb] [ABI] Apply AugmentRegisterInfo() to DynamicRegisterInfo::Registers

Call ABI::AugmentRegisterInfo() once with a vector of all defined
registers rather than calling it for every individual register. Move
and rename RemoteRegisterInfo from gdb-remote to
DynamicRegisterInfo::Register, and use this class when augmenting
registers.

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

show more ...


# 89b57061 08-Oct-2021 Reid Kleckner <[email protected]>

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually us

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

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

show more ...


Revision tags: 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, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2
# 057efa99 11-Feb-2021 Adrian Prantl <[email protected]>

Make the error condition in Value::ValueType explicit (NFC)

The comment for ValueType claims that all values <1 are errors, but
not all switch statements take this into account. This patch
introduce

Make the error condition in Value::ValueType explicit (NFC)

The comment for ValueType claims that all values <1 are errors, but
not all switch statements take this into account. This patch
introduces an explicit Error case and deletes all default: cases, so
we get warned about incomplete switch coverage.

https://reviews.llvm.org/D96537

show more ...


Revision tags: 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
# 5d645743 03-Nov-2020 Pavel Labath <[email protected]>

[lldb] Delete Value::Vector class

This class and it's surroundings contain a lot of shady code, but as far
as I can tell all of that code is unreachable (there is no code actually
setting the value

[lldb] Delete Value::Vector class

This class and it's surroundings contain a lot of shady code, but as far
as I can tell all of that code is unreachable (there is no code actually
setting the value to eValueTypeVector).

According to history this class was introduced in 2012 in
r167033/0665a0f09. At that time, the code seemed to serve some purpose,
and it had two entry points (in Value::SetContext and
ClangExpressionDeclMap::LookupDecl). The first entry point was deleted
in D17897 and the second one in r179842/44342735.

The stated purpose of the patch introducing this class was to fix
TestRegisters.py, and "expr $xmm0" in particular. Both of these things
function perfectly well these days without this class.

show more ...


# 24e07570 13-Oct-2020 Raphael Isemann <[email protected]>

[lldb] Remove all the RegisterInfo name constification code

RegisterInfo's `reg_name`/`reg_alt_name` fields are C-Strings and are supposed
to only be generated from a ConstString. The reason for tha

[lldb] Remove all the RegisterInfo name constification code

RegisterInfo's `reg_name`/`reg_alt_name` fields are C-Strings and are supposed
to only be generated from a ConstString. The reason for that is that
`DynamicRegisterInfo::GetRegisterInfo` and
`RegInfoBasedABI::GetRegisterInfoByName` try to optimise finding registers by
name by only comparing the C string pointer values instead of the underlying
strings. This only works if both C strings involved in the comparison come from
a ConstString. If one of the two C strings doesn't come from a ConstString the
comparison won't work (and most likely will silently fail).

I added an assert in b0060c3a7868ef026d95d0cf8a076791ef74f474 which checks that
both strings come from a ConstString. Apparently not all ABI plugins are
generating their register names via ConstString, so this code is now not just
silently failing but also asserting.

In D88375 we did a shady fix for the MIPS plugins by just copying the
ConstString setup code to that plugin, but we still need to fix ABISysV_arc,
ABISysV_ppc and ABISysV_ppc64 plugins.

I would say we just fix the remaining plugins by removing the whole requirement
to have the register names coming from ConstStrings. I really doubt that we
actually save any time with the whole ConstString search trick (searching ~50
strings that have <4 characters doesn't sound more expensive than calling the
really expensive ConstString constructor + comparing the same amount of pointer
values). Also whatever small percentage of LLDB's runtime is actually spend in
this function is anyway not worth the complexity of this approach.

This patch just removes all this and just does a normal string comparison.

Reviewed By: JDevlieghere, labath

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

show more ...


Revision tags: 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
# 67d67ebe 20-Mar-2020 Jim Ingham <[email protected]>

Internal expressions shouldn't increment the result variable numbering.

There an option: EvaluateExpressionOptions::SetResultIsInternal to indicate
whether the result number should be returned to th

Internal expressions shouldn't increment the result variable numbering.

There an option: EvaluateExpressionOptions::SetResultIsInternal to indicate
whether the result number should be returned to the pool or not. It
got broken when the PersistentExpressionState was refactored.

This fixes the issue and provides a test of the behavior.

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

show more ...


Revision tags: llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3
# b0060c3a 19-Feb-2020 Raphael Isemann <[email protected]>

[lldb] Make comparing RegisterInfo::[alt_]name's pointer value less footy-shooty

Comparing those two `const char *` values relies on the assumption that both
strings were created by a ConstString. L

[lldb] Make comparing RegisterInfo::[alt_]name's pointer value less footy-shooty

Comparing those two `const char *` values relies on the assumption that both
strings were created by a ConstString. Let's check that assumption with an
assert as otherwise this code silently does nothing and that's not great.

show more ...


# 8f95a82b 17-Feb-2020 Jonas Devlieghere <[email protected]>

[lldb] Fix Windows bot.

Should fix error C2039: 'toupper': is not a member of 'std'.


# b2d64b69 17-Feb-2020 Pavel Labath <[email protected]>

[lldb] Fix build error from 07355c1c08b

The error is: no matching function for call to 'transform(std::string&, std::__cxx11::basic_string<char>::iterator, <unresolved overloaded function type>)'

T

[lldb] Fix build error from 07355c1c08b

The error is: no matching function for call to 'transform(std::string&, std::__cxx11::basic_string<char>::iterator, <unresolved overloaded function type>)'

The fix: replace llvm::transform with an equally simple hand-rolled
loop.

show more ...


Revision tags: llvmorg-10.0.0-rc2
# 07355c1c 03-Feb-2020 Pavel Labath <[email protected]>

[lldb] Delete register info definitions in the x86_64 ABI classes

Summary:
These definitions are used to "augment" information received from the remote
target with eh/debug frame and "generic" regis

[lldb] Delete register info definitions in the x86_64 ABI classes

Summary:
These definitions are used to "augment" information received from the remote
target with eh/debug frame and "generic" register numbers.

Besides being verbose, this information was also incomplete (new registers like
xmm16-31 were missing) and sometimes even downright wrong (ymm register
numbers).

Most of this information is available via llvm's MCRegisterInfo. This patch
creates a new class, MCBasedABI, which retrieves the eh and debug frame register
numbers this way. The tricky part here is that the llvm class uses all-caps
register names, whereas lldb register are lowercase, and sometimes called
slightly differently. Therefore this class introduces some hooks to allow a
subclass to customize the MC lookup. The subclass also needs to suply the
"generic" register numbers, as this is an lldb invention.

This patch ports the x86_64 ABI classes to use the new register info mechanism.
It also creates a new "ABIx86_64" class which can be used to house code common
to x86_64 both ABIs. Right now, this just consists of a single function, but
there are plenty of other things that could be moved here too.

Reviewers: JDevlieghere, jasonmolenda

Subscribers: mgorny, lldb-commits

Tags: #lldb

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

show more ...


# 12e32d32 02-Feb-2020 Pavel Labath <[email protected]>

[lldb] Introduce "RegInfoBasedABI"

Summary:
This patch creates a new subclass of the ABI class in order to abstract away the
mechanism in which we "augment" register information. This enables altern

[lldb] Introduce "RegInfoBasedABI"

Summary:
This patch creates a new subclass of the ABI class in order to abstract away the
mechanism in which we "augment" register information. This enables alternate
augmentation strategies to be introduced.

All existing ABI classes have been modified to inherit from RegInfoBasedABI, but
they will be refactored in subsequent patches.

Reviewers: JDevlieghere, jasonmolenda

Subscribers: sdardis, nemanjai, kbarton, jrtc27, atanasyan, jsji, lldb-commits

Tags: #lldb

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

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
# e9331a56 08-Jan-2020 Adrian Prantl <[email protected]>

Add missing nullptr checks.

GetPersistentExpressionStateForLanguage() can return a nullptr if it
cannot construct a typesystem. This patch adds missing nullptr checks
at all uses.

Inspired by rdar:

Add missing nullptr checks.

GetPersistentExpressionStateForLanguage() can return a nullptr if it
cannot construct a typesystem. This patch adds missing nullptr checks
at all uses.

Inspired by rdar://problem/58317195

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

show more ...


Revision tags: llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2
# 2b8db387 03-Dec-2019 Pavel Labath <[email protected]>

[lldb] Move register info "augmentation" from gdb-remote into ABI

Summary:
Previously the ABI plugin exposed some "register infos" and the
gdb-remote code used those to fill in the missing bits. Now

[lldb] Move register info "augmentation" from gdb-remote into ABI

Summary:
Previously the ABI plugin exposed some "register infos" and the
gdb-remote code used those to fill in the missing bits. Now, the
"filling in" code is in the ABI plugin itself, and the gdb-remote code
just invokes that.

The motivation for this is two-fold:
a) the "augmentation" logic is useful outside of process gdb-remote. For
instance, it would allow us to avoid repeating the register number
definitions in minidump code.
b) It gives more implementation freedom to the ABI classes. Now that
these "register infos" are essentially implementation details, classes
can use other methods to obtain dwarf/eh_frame register numbers -- for
instance they can consult llvm MC layer.

Since the augmentation code was not currently tested anywhere, I took
the opportunity to create a simple test for it.

Reviewers: jasonmolenda, clayborg, tatyana-krasnukha

Subscribers: aprantl, lldb-commits

Tags: #lldb

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

show more ...


Revision tags: llvmorg-9.0.1-rc1
# d0b44dbe 25-Sep-2019 Pavel Labath <[email protected]>

Have ABI plugins vend llvm MCRegisterInfo data

Summary:
I was recently surprised to learn that there is a total of 2 (two) users
of the register info definitions contained in the ABI plugins. Yet, t

Have ABI plugins vend llvm MCRegisterInfo data

Summary:
I was recently surprised to learn that there is a total of 2 (two) users
of the register info definitions contained in the ABI plugins. Yet, the
defitions themselves span nearly 10kLOC.
The two users are:
- dwarf expression pretty printer
- the mechanism for augmenting the register info definitions obtained
over gdb-remote protocol (AugmentRegisterInfoViaABI)

Both of these uses need the DWARF an EH register numbers, which is
information that is already available in LLVM. This patch makes it
possible to do so.

It adds a GetMCRegisterInfo method to the ABI class, which every class
is expected to implement. Normally, it should be sufficient to obtain
the definitions from the appropriate llvm::Target object (for which I
provide a utility function), but the subclasses are free to construct it
in any way they deem fit.

We should be able to always get the MCRegisterInfo object from llvm,
with one important exception: if the relevant llvm target was disabled
at compile time. To handle this, I add a mechanism to disable the
compilation of ABI plugins based on the value of LLVM_TARGETS_TO_BUILD
cmake setting. This ensures all our existing are able to create their
MCRegisterInfo objects.

The new MCRegisterInfo api is not used yet, but the intention is to make
use of it in follow-up patches.

Reviewers: jasonmolenda, aprantl, JDevlieghere, tatyana-krasnukha

Subscribers: wuzish, nemanjai, mgorny, kbarton, atanasyan, lldb-commits

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

llvm-svn: 372862

show more ...


Revision tags: 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
# e574f8b3 17-Jul-2019 Alex Langford <[email protected]>

[Target][NFCI] Rename variable

This variable doesn't have anything to do with clang.

llvm-svn: 366292


Revision tags: llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2
# 4dc0acc9 31-May-2019 Alex Langford <[email protected]>

[Target] Remove ABI's dependence on ExpressionParser

llvm-svn: 362259


Revision tags: llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4
# 0e4c4821 06-Mar-2019 Adrian Prantl <[email protected]>

Pass ConstString by value (NFC)

My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.

ConstString has exactly one const char * data member, s

Pass ConstString by value (NFC)

My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.

ConstString has exactly one const char * data member, so passing a
ConstString by reference is not any more efficient than copying it by
value. In both cases a single pointer is passed. But passing it by
value makes it harder to accidentally return the address of a local
object.

(This fixes rdar://problem/48640859 for the Apple folks)

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

llvm-svn: 355553

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


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, 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
# 03219f7f 30-Apr-2018 Adrian Prantl <[email protected]>

Refactor GetNextPersistentVariableName into a non-virtual method
that takes a prefix string. This simplifies the implementation and
allows plugins such as the Swift plugin to supply different prefixe

Refactor GetNextPersistentVariableName into a non-virtual method
that takes a prefix string. This simplifies the implementation and
allows plugins such as the Swift plugin to supply different prefixes
for return and error variables.

rdar://problem/39299889

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

llvm-svn: 331235

show more ...


# 5435f780 30-Apr-2018 Adrian Prantl <[email protected]>

Move the persistent variable counter into Target
so it can be shared across multiple language plugins.

In a multi-language project it is counterintuitive to have a result
variables reuse numbers jus

Move the persistent variable counter into Target
so it can be shared across multiple language plugins.

In a multi-language project it is counterintuitive to have a result
variables reuse numbers just because they are using a different
language plugin in LLDB (but not for example, when they are
Objective-C versus C++, since they are both handled by Clang).

This is NFC on llvm.org except for the Go plugin.

rdar://problem/39299889

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

llvm-svn: 331234

show more ...


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


12