| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Uses the `TrackingOutputBuffer` to populate the new member `Mangled::m_demangled_info`.
`m_demangled_info` is lazily popluated by `GetDemangledInfo`. To ensure `m_demangled` and `m_demangled_info` are in-sync we clear `m_demangled_info` anytime `m_demangled` is set/cleared.
https://github.com/llvm/llvm-project/pull/131836
|
|
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.
|
|
Currently, `llvm-cxxfilt` will strip the leading underscore of its input
on macOS. Historically MachO symbols were prefixed with an extra
underscore and this is why this default exists. However, nowadays, the
`ItaniumDemangler` supports all of the following mangling prefixes:
`_Z`, `__Z`, `___Z`, `____Z`. So really `llvm-cxxfilt` can simply
forward the mangled name to the demangler and let the library decide
whether it's a valid encoding.
Compiling C++ on macOS nowadays will generate symbols with `_Z` and
`___Z` prefixes. So users trying to demangle these symbols will have to
know that they need to add the `-n` prefix. This routinely catches
people off-guard.
This patch removes the `-n` default for macOS and allows calling into
the `ItaniumDemangler` with all the `_Z` prefixes that the demangler
supports (1-4 underscores).
rdar://132714940
|
|
|
|
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.
|
|
Added -p / --no-params flag to skip demangling function parameters
similar to how it is supported by GNU c++filt tool.
There are cases when users want to demangle a large number of symbols in
bulk, for example, at startup, and do not care about function parameters
and overloads at that time. Skipping the demangling of parameter types
led to a measurable improvement in performance. Our users reported about
15% speed up with GNU c++filt and we expect similar results with
llvm-cxxfilt with this patch.
|
|
This reverts commit 71f8ea3062a6b0a190835853ee77e58469763b9e.
Test doesn't pass on mac. See comments on
https://github.com/llvm/llvm-project/pull/75348.
|
|
Added -p / --no-params flag to skip demangling function parameters
similar to how it is supported by GNU c++filt tool.
There are cases when users want to demangle a large number of symbols in
bulk, for example, at startup, and do not care about function parameters
and overloads at that time. Skipping the demangling of parameter types
led to a measurable improvement in performance. Our users reported about
15% speed up with GNU c++filt and we expect similar results with
llvm-cxxfilt with this patch.
|
|
symbol name.
Summary:
In AIX OS, function entry label are begin with '.', it can not be decoded currently.
we support to decode the name in this patch for all OS.
Reviewers: Fangrui Song, James Henderson,
Differential Revision: https://reviews.llvm.org/D139864
|
|
The called std::terminate currently gets the declaration transitively
through llvm/Demangle/Utility.h, removing <exception> from Utility.h
would break ItaniumDemangle.cpp.
|
|
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
|
|
const std::string&
As suggested by @erichkeane in
https://reviews.llvm.org/D141451#inline-1429549
There's potential for a lot more cleanups around these APIs. This is
just a start.
Callers need to be more careful about sub-expressions producing strings
that don't outlast the expression using `llvm::demangle`. Add a
release note.
Differential Revision: https://reviews.llvm.org/D149104
|
|
Many existing methods of the D Language Demangler take a C style string
and return an adjusted pointer to the same object as the input string is
consumed.
Make it more obvious by changing the signatures to accept
std::string_view& when the input is modified vs a copy of a
std::string_view when the input is not.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D152177
|
|
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
|
|
This was originally a part of D149104 which was backed out. This change
is uncontroversial though, so split it out and reland it.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D152042
|
|
I was doing this API conversion to use std::string_view top-down in
D149104, but this exposed issues in individual demanglers that needed to
get fixed first. There's no issue with the conversion for the D language
demangler, so convert it.
I have a more aggressive refactoring of the entire D language demangler
to use std::string_view more extensively, but the interface with
llvm::nonMicrosoftDemangle is the more interesting one.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D151003
|
|
I was doing this API conversion to use std::string_view top-down in
D149104, but this exposed issues in individual demanglers that needed to
get fixed first. There's no issue with the conversion for the Rust
demangler, so convert it first.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D149784
|
|
std::string_view
D149104 converted llvm::demangle to use std::string_view. Enabling
"expensive checks" (via -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON) causes
lld/test/wasm/why-extract.s to fail. The reason for this is obscure:
Reason #10007 why std::string_view is dangerous:
Consider the following pattern:
std::string_view s = ...;
const char *c = s.data();
std::strlen(c);
Is c a NUL-terminated C style string? It depends; but if it's not then
it's not safe to call std::strlen on the std::string_view::data().
std::string_view::length() should be used instead.
Fixing this fixes the one lone test that caught this.
microsoftDemangle, rustDemangle, and dlangDemangle should get this same
treatment, too. I will do that next.
Reviewed By: MaskRay, efriedma
Differential Revision: https://reviews.llvm.org/D149675
|
|
No call sites interpreted this value meaningfully. Simplify this
interface.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D149707
|
|
No call sites use these parameters, so drop them.
Equivalent to D148940.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D149703
|
|
const std::string&"
This reverts commit c117c2c8ba4afd45a006043ec6dd858652b2ffcc.
itaniumDemangle calls std::strlen with the results of
std::string_view::data() which may not be NUL-terminated. This causes
lld/test/wasm/why-extract.s to fail when "expensive checks" are enabled
via -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON. See D149675 for further
discussion. Back this out until the individual demanglers are converted
to use std::string_view.
|
|
std::string&
As suggested by @erichkeane in
https://reviews.llvm.org/D141451#inline-1429549
There's potential for a lot more cleanups around these APIs. This is
just a start.
Callers need to be more careful about sub-expressions producing strings
that don't outlast the expression using ``llvm::demangle``. Add a
release note.
Reviewed By: MaskRay, #lld-macho
Differential Revision: https://reviews.llvm.org/D149104
|
|
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
|
|
Toward the goal of replacing llvm::StringView with std::string_view,
first replacing users of llvm::StringView::dropFront, this case in the
Rust demangling scheme seemed worth its own commit+review.
Reviewed By: erichkeane, MaskRay
Differential Revision: https://reviews.llvm.org/D148272
|
|
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
|
|
The demangler is not supposed to include bits of LLVM, so it can't use STLExtras.
This undoes part of 6d9cd9199a6fdeab0412117bcefc28f625510b61
|
|
|
|
|
|
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 rust demangler has some odd buffer handling code, which will copy
the demangled string into the provided buffer, if it will fit.
Otherwise it uses the allocated buffer it made. But the length of the
incoming buffer will have come from a previous call, which was the
length of the demangled string -- not the buffer size. And of course,
we're unconditionally allocating a temporary buffer in the first
place. So we don't actually get buffer reuse, and we get a memcpy in
somecases.
However, nothing in LLVM ever passes in a non-null pointer. Neither
does anything pass in a status pointer that is then made use of. The
only exercise these have is in the test suite.
So let's just make the rust demangler have the same API as the dlang
demangler.
Reviewed By: tmiasko
Differential Revision: https://reviews.llvm.org/D123420
|
|
Add contents to the demangler node dumper's print(Prec) functions.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D122740
|
|
The demangler has a utility class 'SwapAndRestore'. That name is
confusing. It's not swapping anything, and the restore part happens at
the object's destruction. What it's actually doing is allowing a
override of some value that is dynamically accessible within the
lifetime of a lexical scope. Thus rename it to ScopedOverride, and
tweak it's member variable names.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D122606
|
|
Not sure if this could use more testing, but hopefully this is adequate.
|
|
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
|
