| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The qualifier allows programmer to directly control how pointers are
signed when they are stored in a particular variable.
The qualifier takes three arguments: the signing key, a flag specifying
whether address discrimination should be used, and a non-negative
integer that is used for additional discrimination.
```
typedef void (*my_callback)(const void*);
my_callback __ptrauth(ptrauth_key_process_dependent_code, 1, 0xe27a) callback;
```
Co-Authored-By: John McCall rjmccall@apple.com
|
|
(#134483)
Static analysis detected that Demangler::demangleStringLiteral had a
potential overflow if not checking StringByteSize properly.
Added check to ensure that for wide string it is always even and that
there were the byte count did not mismatch the actual size of the
literal.
Fixes: https://github.com/llvm/llvm-project/issues/129970
|
|
Arm64EC uses a special name mangling mode that adds `$$h` between the
symbol name and its type. In MSVC's name mangling `@` is used to
separate the name and type BUT it is also used for other purposes, such
as the separator between paths in a fully qualified name.
The original algorithm was quite fragile and made assumptions that
didn't hold true for all MSVC mangled symbols, so instead of trying to
improve this algorithm we are now using the demangler to indicate where
the insertion point should be (i.e., to parse the fully-qualified name
and return the current string offset).
Also fixed `isArm64ECMangledFunctionName` to search for `@$$h` since the
`$$h` must always be after a `@`.
Fixes #115231
|
|
Properly demangle `_T` and `_P` return type manglings for MSVC 1920+.
Also added a unit test for `@` return type that is used when mangling
non-template auto placeholder return type function.
Tested the output against the undname shipped with MSVC 19.40.
|
|
Fixes https://github.com/llvm/llvm-project/issues/70899.
This is a continuation of
https://github.com/llvm/llvm-project/pull/92477 for pointers to member
data and pointers to member functions.
The mangled name must be prefixed with `$M <mangled-type>` for the
deduced type of the nttp parameter.
|
|
pointer to data and integral types (#96590)
As cited here, https://github.com/llvm/llvm-project/pull/92477, undname
needs updating to support the new auto NTTP name mangling.
In short the deduced type of the auto NTTP parameter is mangled as `$M
<type> <nttp-param>`. However the deduced type is not printed for the
undecorated name so the `$M <type>` is parsed but simply ignored when
stringifying the generated AST.
|
|
To fix expensive check builds that were failing when using MSVC's
std::string_view::iterator::operator*, I added a few expressions like
&*std::string_view::begin. @nico pointed out that this is literally the
same thing and more clearly expressed as std::string_view::data.
Link: https://github.com/llvm/llvm-project/issues/63740
Reviewed By: #libc_abi, ldionne, philnik, MaskRay
Differential Revision: https://reviews.llvm.org/D154876
|
|
A follow up to commit 6bad76c7ae93 ("[Demangle] fix windows tests")
based on @thakis' report.
Fixes: #63740
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D154875
|
|
This should be last of the "bottom-up conversions" of various demanglers
to accept std::string_view. After this, D149104 may be revisited.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D152176
|
|
No call sites use these parameters, so drop them.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D148940
|
|
My reland of https://reviews.llvm.org/D148546 has caused a few windows
demangler tests to fail when run with -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON
on windows.
I have a sneaking suspicion that MSVC's
std::string_view::iterator::operator* may be missing a nullptr check.
Link: https://lab.llvm.org/buildbot/#/builders/42/builds/9723/steps/7/logs/stdio
Reviewed By: ayzhao
Differential Revision: https://reviews.llvm.org/D148852
|
|
This reverts commit d81cdb49d74064e88843733e7da92db865943509.
This refactoring was waiting on converting LLVM to C++17.
Leave StringView.h and cleanup around for subsequent cleanup.
Additional fixes for missing std::string_view conversions for MSVC.
Reviewed By: MaskRay, DavidSpickett, ayzhao
Differential Revision: https://reviews.llvm.org/D148546
|
|
This reverts commit 3e559509b426b6aae735a7f57dbdaed1041d2622 and e0c4ffa796b553fa78c638a9584c05ac21fe07d5.
This still breaks Windows builds.
In addition, `#include <llvm/ADT/StringViewExtras.h>` in
llvm/include/llvm/Demangle/ItaniumDemangle.h is a library layering violation
(LLVMDemangle is the lowest LLVM library and cannot depend on LLVMSupport).
|
|
Fixes diagnostics reported against
https://reviews.llvm.org/D148384
https://lab.llvm.org/buildbot/#/builders/127/builds/46749/steps/4/logs/stdio
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D148392
|
|
This refactoring was waiting on converting LLVM to C++17.
Leave StringView.h and cleanup around for subsequent cleanup.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D148384
|
|
Towards converting our use of llvm::StringView to std::string_view,
remove a method that std::string_view doesn't have.
This could be moved to the nascent llvm/ADT/StringViewExtras.h, but the
use is highly localized to one TU. Move this to be a static function
there.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D148375
|
|
Towards converting our use of llvm::StringView to std::string_view,
remove a method that std::string_view doesn't have.
llvm::StringView::popFront is similar to std::string_view::remove_prefix
but with a reference to std::string_view::front taken first.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D148363
|
|
Towards replacing llvm::StringView with std::string_view, remove ctor
that std::string_view doesn't have an analog for.
Reviewed By: erichkeane, MaskRay
Differential Revision: https://reviews.llvm.org/D148353
|
|
Towards converting our use of llvm::StringView to std::string_view,
remove a method that std::string_view doesn't have.
llvm::StringView::dropFront is semantically similar to
std::string_view::substr but with the input clamped to the size. No code
was relying on clamping other than the rust demangler, which I fixed in
https://reviews.llvm.org/D148272. Removing this method makes it easier
to switch over code later.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D148348
|
|
llvm::itanium_demangle::StringView::{dropBack,dropFront}. NFC
Make it easier to migrate StringView to std::string_view.
|
|
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.
Some adjustment to a couple of uses is needed, due to the lazy buffer
creation of this patch.
a) the Microsoft demangler can demangle empty strings to nothing,
which it then memoizes. We need to avoid the UB of passing nullptr to
memcpy.
b) a unit test checks insertion of no characters into an empty buffer.
We need to avoid UB when converting that to std::string.
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
|
|
|
|
Reverting due to a bot failure:
https://lab.llvm.org/buildbot/#/builders/5/builds/22738
This reverts commit 5b3ca24a35e91bf9c19af856e7f92c69b17f989e.
|
|
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
|
|
The emission was corrected for the swift_async calling convention but
the demangling support was not. This repairs the demangling support as
well.
|
|
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 reverts commit 9b962d83ece841e43fd2823375dc6ddc94c1b178.
This didn't address the underlying issue (in MicrosoftDemangleNodes.h)
that was fixed 6 months ago anyway.
|
|
|
|
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
|
|
llvm-svn: 373450
|
|
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
|
|
FunctionSignatureNode already had an IsVariadic field,
but it wasn't used anywhere yet. Set it and use it.
llvm-svn: 362541
|
|
- 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
|
|
llvm-svn: 362536
|
|
- 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
|
|
llvm-svn: 362333
|
|
Ports clang's mangling support added in r354633 to llvm-undname.
llvm-svn: 361839
|
|
llvm-svn: 361835
|
|
llvm-svn: 361786
|
|
llvm-svn: 361783
|
|
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
|
