Every non-testcase use of OutputBuffer contains code to allocate an
initial buffer (using either 128 or 1024 as initial guesses). There's
now no need to do that, given recent changes to the buffer extension
heuristics -- it allocates a 1k(ish) buffer on first need.
Just pass in a buffer (if any) to the constructor. Thus the
OutputBuffer's ownership of the buffer starts at its own lifetime
start. We can reduce the lifetime of this object in several cases.
That new constructor takes a 'size_t *' for the size argument, as all
uses with a non-null buffer are passing through a malloc'd buffer from
their own caller in this manner.
The buffer reset member function is never used, and is deleted.
The original buffer initialization code would return a failure code if
that first malloc failed. Existing code either ignored that, called
std::terminate with a FIXME, or returned an error code.
But that's not foolproof anyway, as a subsequent buffer extension
failure ends up calling std::terminate. I am working on addressing
that unfortunate failure mode in a manner more consistent with the C++
ABI design.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D122604
The OutputBuffer class tries to present a NUL-terminated string API to
consumers. But several of them would prefer a StringView. In
particular the Microsoft demangler, juggles between NUL-terminated and
StringView, which is confusing.
This adds a StringView conversion, and adjusts the Demanglers that can
benefit from that.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D120990
The microsoft demangler makes copies of the demangled strings, but has
some confusion between StringView representation (sans NUL), and
C-strings (with NUL). Here we also have a use of strcpy, which
happens to work because the incoming string view happens to have a
trailing NUL. But a simple memcpy excluding the NUL is sufficient.
Reviewed By: dblaikie, erichkeane
Differential Revision: https://reviews.llvm.org/D122391
This patch is a refactor to implement prepend afterwards. Since this changes a lot of files and to conform with guidelines, I will separate this from the implementation of prepend. Related to the discussion in https://reviews.llvm.org/D111414 , so please read it for more context.
Reviewed By: #libc_abi, dblaikie, ldionne
Differential Revision: https://reviews.llvm.org/D111947
When printing names in lldb on windows these names contain the full type information while on linux only the name is contained.
This change introduces a flag in the Microsoft demangler to control if the type information should be included.
With the flag enabled demangled name contains only the qualified name, e.g:
without flag -> with flag
int (*array2d)[10] -> array2d
int (*abc::array2d)[10] -> abc::array2d
const int *x -> x
For globals there is a second inconsistency which is not yet addressed by this change. On linux globals (in global namespace) are prefixed with :: while on windows they are not.
Reviewed By: teemperor, rnk
Differential Revision: https://reviews.llvm.org/D111715
This change is intended as initial setup. The plan is to add
more semantic checks later. I plan to update the documentation
as more semantic checks are added (instead of documenting the
details up front). Most of the code closely mirrors that for
the Swift calling convention. Three places are marked as
[FIXME: swiftasynccc]; those will be addressed once the
corresponding convention is introduced in LLVM.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D95561
Previously, Clang was able to mangle the Swift calling
convention but 'MicrosoftDemangle.cpp' was not able to demangle it.
Reviewed By: compnerd, rnk
Differential Revision: https://reviews.llvm.org/D95053
Demangling Itanium symbols either consumes the whole input or fails,
but Microsoft symbols can be successfully demangled with just some
of the input.
Add an outparam that enables clients to know how much of the input was
consumed, and use this flag to give llvm-undname an opt-in warning
on partially consumed symbols.
Differential Revision: https://reviews.llvm.org/D80173
This corresponds to commonly used options to UnDecorateSymbolName
within llvm.
Add them as hidden options in llvm-undname. MS undname.exe takes
numeric flags, corresponding to the UNDNAME_* constants, but instead
of hardcoding in mappings for those numbers, just add textual
options instead, as it the use of them here is primarily intended
for testing.
Differential Revision: https://reviews.llvm.org/D68917
llvm-svn: 374865
typeinfo names aren't symbols but string constant contents
stored in compiler-generated typeinfo objects, but llvm-cxxfilt
can demangle these for Itanium names.
In the MSVC ABI, these are just a '.' followed by a mangled
type -- this means they don't start with '?' like all MS-mangled
symbols do.
Differential Revision: https://reviews.llvm.org/D67851
llvm-svn: 372602
- The loop in demangleFunctionParameterList() only exits
on Error, @, and Z. All 3 cases were handled, so the
rest of the function is DEMANGLE_UNREACHABLE.
- The loop in demangleTemplateParameterList() always returns
on Error, so there's no need to check for that in the loop
header and after the loop.
- Add test cases for invalid function parameter manglings.
- Add a (redundant) test case for a simple template parameter
list mangling.
- Add a test case pointing out that varargs functions aren't
demangled correctly.
llvm-svn: 362540
- For error returns in demangleSpecialTableNode(),
demangleLocalStaticGuard(), RTTITypeDescriptor,
demangleRttiBaseClassDescriptorNode(), demangleUnsigned(),
demangleUntypedVariable() (via RttiBaseClassArray)
- For ?_A and ?_P which are handled at early levels of the
demangler but are not implemented in a later stage; this
is now more obvious
- Replace a "default:" with an explicit list of cases, to
get -Wswitch check we list all cases
llvm-svn: 362520
- Add test coverage around invalid anon namespaces and
for error paths in demanglePrimitiveType() and in
demangleFullyQualifiedTypeName()
- Use DEMANGLE_UNREACHABLE in two more unreachable places
llvm-svn: 362514
- Replace `Error = true` in a few branches that are truly unreachable
with DEMANGLE_UNREACHABLE
- Remove early return early in startsWithLocalScopePattern() because
it's redundant with the next two early returns
- Remove unreachable `case '0'` (it's handled in the branch below)
- Remove an unused bool return
- Add test coverage for several early error returns, mostly in
array type parsing
llvm-svn: 362506
Also add two FC_Far that seem to be missing, by symmetry from
the public and protected cases. (But FC_Far isn't really a thing
anymore, so this doesn't really have an observable effect.)
llvm-svn: 362344
Demangler::parse() for MD5 names would:
1. Put all remaining text into the MD5 name sight unseen
2. Not modify MangledName
This meant that if the demangler recursively called parse() (e.g. in
demangleLocallyScopedNamePiece()), every recursive call that started on
an MD5 name would add all remaining bytes to the output buffer but
only advance the input by a byte. For valid inputs, MD5 types are
never (well, see comments for 2 exceptions) nested, but for invalid
input this could cause memory use quadratic in the input size.
llvm-svn: 361744
If a template parameter refers to a pointer to member, but the mangling
of that was a string literal instead of a real symbol, llvm-undname used
to crash instead of rejecting the input.
llvm-svn: 361402
llvm-undname used to put '\x' in front of every pair of nibbles, but
u"\xD7\xFF" produces a string with 6 bytes: \xD7 \0 \xFF \0 (and \0\0). Correct
for a single character (plus terminating \0) is u\xD7FF instead.
Now, wchar_t, char16_t, and char32_t strings roundtrip from source to
clang-cl (and cl.exe) and then llvm-undname.
(...at least as long as it's not a string like L"\xD7FF" L"foo" which
gets demangled as L"\xD7FFfoo", where the compiler then considers the
"f" as part of the hex escape. That seems ok.)
Also add a comment saying that the "almost-valid" char32_t string I
added in my last commit is actually produced by compilers.
llvm-svn: 358857
If a unsigned with all 4 bytes non-0 was passed to outputHex(), there
were two off-by-ones in it:
- Both MaxPos and Pos left space for the final \0, which left the buffer
one byte to small. Set MaxPos to 16 instead of 15 to fix.
- The `assert(Pos >= 0);` was after a `Pos--`, move it up one line.
Since valid Unicode codepoints are <= 0x10ffff, this could never really
happen in practice.
Found by oss-fuzz.
llvm-svn: 358856
- Don't assert when a string looks like a u32 string to the heuristic
but doesn't have a length that's 0 mod 4. Instead, classify those
as u16 with embedded \0 chars. Found by oss-fuzz.
- Print embedded nul bytes as \0 instead of \x00.
llvm-svn: 358835
Similar to r358421: A StructorIndentifierNode has a Class field which
is read when printing it, but if the StructorIndentifierNode appears in
a template argument then demangleFullyQualifiedSymbolName() which sets
Class isn't called. Since StructorIndentifierNodes are always leaf
names, we can just reject them as well.
Found by oss-fuzz.
llvm-svn: 358491
A ConversionOperatorIdentifierNode has a TargetType which is read when
printing it, but if the ConversionOperatorIdentifierNode appears in a
template argument there's nothing that can provide the TargetType.
Normally the COIN is a symbol (leaf) name and takes its TargetType from the
symbol's type, but in a template argument context the COIN can only be
either a non-leaf name piece or a type, and must hence be invalid.
Similar to the COIN check in demangleDeclarator().
Found by oss-fuzz.
llvm-svn: 358421
Kirill Stoimenov