[llvm-cxxfilt][macOS] Don't strip underscores on macOS by default (#106233)

Currently, `llvm-cxxfilt` will strip the leading underscore of its input
on macOS. Historically MachO symbols were prefix

[llvm-cxxfilt][macOS] Don't strip underscores on macOS by default (#106233)

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

show more ...

[llvm-cxxfilt] Added the option --no-params (#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 user

[llvm-cxxfilt] Added the option --no-params (#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.

show more ...

Revert "[llvm-cxxfilt] Added the option --no-params (#75348)"

This reverts commit 71f8ea3062a6b0a190835853ee77e58469763b9e.

Test doesn't pass on mac. See comments on
https://github.com/llvm/llvm-pr

Revert "[llvm-cxxfilt] Added the option --no-params (#75348)"

This reverts commit 71f8ea3062a6b0a190835853ee77e58469763b9e.

Test doesn't pass on mac. See comments on
https://github.com/llvm/llvm-project/pull/75348.

show more ...

[llvm-cxxfilt] Added the option --no-params (#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 u

[llvm-cxxfilt] Added the option --no-params (#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.

show more ...

[llvm-cxxfilt] Do not consider the prefix dot as part of the demangled symbol name.

Summary:

In AIX OS, function entry label are begin with '.', it can not be decoded currently.
we support to decod

[llvm-cxxfilt] Do not consider the prefix dot as part of the demangled 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

show more ...

reland: [Demangle] make llvm::demangle take std::string_view rather than const std::string&

As suggested by @erichkeane in
https://reviews.llvm.org/D141451#inline-1429549

There's potential for a lo

reland: [Demangle] make llvm::demangle take std::string_view rather than 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

show more ...

[Demangle] convert is*Encoding to use std::string_view

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:

[Demangle] convert is*Encoding to use std::string_view

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

show more ...

[Damangle] convert dlangDemangle to use std::string_view

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

[Damangle] convert dlangDemangle to use std::string_view

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

show more ...

[Damangle] convert rustDemangle to use std::string_view

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
g

[Damangle] convert rustDemangle to use std::string_view

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

show more ...

[Demangle] convert itaniumDemangle and nonMicrosoftDemangle to use std::string_view

D149104 converted llvm::demangle to use std::string_view. Enabling
"expensive checks" (via -DLLVM_ENABLE_EXPENSIVE

[Demangle] convert itaniumDemangle and nonMicrosoftDemangle to use 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

show more ...

[Demangle] remove unused status param of itaniumDemangle

No call sites interpreted this value meaningfully. Simplify this
interface.

Reviewed By: MaskRay

Differential Revision: https://reviews.llv

[Demangle] remove unused status param of itaniumDemangle

No call sites interpreted this value meaningfully. Simplify this
interface.

Reviewed By: MaskRay

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

show more ...

[Demangle] remove unused params of itaniumDemangle

No call sites use these parameters, so drop them.
Equivalent to D148940.

Reviewed By: MaskRay

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

[Demangle] remove unused params of itaniumDemangle

No call sites use these parameters, so drop them.
Equivalent to D148940.

Reviewed By: MaskRay

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

show more ...

Revert "[Demangle] make llvm::demangle take std::string_view rather than const std::string&"

This reverts commit c117c2c8ba4afd45a006043ec6dd858652b2ffcc.

itaniumDemangle calls std::strlen with the

Revert "[Demangle] make llvm::demangle take std::string_view rather than 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.

show more ...

[Demangle] make llvm::demangle take std::string_view rather than const std::string&

As suggested by @erichkeane in
https://reviews.llvm.org/D141451#inline-1429549

There's potential for a lot more c

[Demangle] make llvm::demangle take std::string_view rather than 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.

Reviewed By: MaskRay, #lld-macho

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

show more ...

[Demangle] remove unused params of microsoftDemangle

No call sites use these parameters, so drop them.

Reviewed By: MaskRay

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

[demangler] Rust demangler buffer return

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 al

[demangler] Rust demangler buffer return

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

show more ...

[Demangle] Add minimal support for D programming language

This patch adds minimal support for D programming language demangling on LLVM
core based on the D name mangling spec. This will allow easier

[Demangle] Add minimal support for D programming language

This patch adds minimal support for D programming language demangling on LLVM
core based on the D name mangling spec. This will allow easier integration on a
future LLDB plugin for D either in the upstream tree or outside of it.

Minimal support includes recognizing D demangling encoding and at least one
mangling name, which in this case is `_Dmain` mangle.

Reviewed By: jhenderson, lattner

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

show more ...

[Demangle] Extract nonMicrosoftDemangle from llvm::demangle

Introduce a new demangling function that supports symbols using Itanium
mangling and Rust v0 mangling, and is expected in the near future

[Demangle] Extract nonMicrosoftDemangle from llvm::demangle

Introduce a new demangling function that supports symbols using Itanium
mangling and Rust v0 mangling, and is expected in the near future to
include support for D mangling as well.

Unlike llvm::demangle, the function does not accept extra underscore
decoration. The callers generally know exactly when symbols should
include the extra decoration and so they should be responsible for
stripping it.

Functionally the only intended change is to allow demangling Rust
symbols with an extra underscore decoration through llvm::demangle,
which matches the existing behaviour for Itanium symbols.

Reviewed By: dblaikie, jhenderson

Part of https://reviews.llvm.org/D110664

show more ...

[Demangle] Support Rust v0 mangling scheme in llvm::demangle

The llvm::demangle is currently used by llvm-objdump and llvm-readobj,
so this effectively adds support for Rust v0 mangling to those
app

[Demangle] Support Rust v0 mangling scheme in llvm::demangle

The llvm::demangle is currently used by llvm-objdump and llvm-readobj,
so this effectively adds support for Rust v0 mangling to those
applications.

Reviewed By: dblaikie

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

show more ...

[NFC] Use std::free instead of ::free

Since we include <cstdlib> instead of <stdlib.h>, it makes sense to
use std::free.

Give microsoftDemangle() an outparam for how many input bytes were consumed.

Demangling Itanium symbols either consumes the whole input or fails,
but Microsoft symbols can be successfully demangled

Give microsoftDemangle() an outparam for how many input bytes were consumed.

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

show more ...

Add missing include (cstdlib) to Demangle.h

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

llvm-svn: 351861

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

Add __[_[_]]Z demangling to new common demangle function

This is a follow-up to r351448. It adds support for other _*Z extensions
of the Itanium demanling, to the newly available demangle function
h

Add __[_[_]]Z demangling to new common demangle function

This is a follow-up to r351448. It adds support for other _*Z extensions
of the Itanium demanling, to the newly available demangle function
heuristic.

Reviewed by: erik.pilkington, rupprecht, grimar

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

llvm-svn: 351551

show more ...

Move demangling function from llvm-objdump to Demangle library

This allows it to be used in an upcoming llvm-readobj change.

A small change in internal behaviour of the function is to always call
t

Move demangling function from llvm-objdump to Demangle library

This allows it to be used in an upcoming llvm-readobj change.

A small change in internal behaviour of the function is to always call
the microsoftDemangle function if the string does not have an itanium
encoding prefix, rather than only if it starts with '?'. This is
harmless because the microsoftDemangle function does the same check
already.

Reviewed by: grimar, erik.pilkington

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

llvm-svn: 351448

show more ...