[XRay][RISCV] RISCV support for XRay (#117368)

Add RISC-V support for XRay. The RV64 implementation has been tested in
both QEMU and in our hardware environment.

Currently this requires D and C

[XRay][RISCV] RISCV support for XRay (#117368)

Add RISC-V support for XRay. The RV64 implementation has been tested in
both QEMU and in our hardware environment.

Currently this requires D and C extensions, but since both RV64GC and
RVA22/RVA23 are becoming mainstream, I don't think this requirement will
be a big problem.

Based on the previous work by @a-poduval :
https://reviews.llvm.org/D117929

---------

Co-authored-by: Ashwin Poduval <ashwin.poduval@gmail.com>

show more ...

[XRay] Add initial support for loongarch64

Only support patching FunctionEntry/FunctionExit/FunctionTailExit for now.

Reviewed By: MaskRay, xen0n
Co-Authored-By: zhanglimin <zhanglimin@loongson.cn>

[XRay] Add initial support for loongarch64

Only support patching FunctionEntry/FunctionExit/FunctionTailExit for now.

Reviewed By: MaskRay, xen0n
Co-Authored-By: zhanglimin <zhanglimin@loongson.cn>

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

show more ...

[NFC][TargetParser] Remove llvm/ADT/Triple.h

I also ran `git clang-format` to get the headers in the right order for
the new location, which has changed the order of other headers in two
files.

[llvm] Use std::optional instead of Optional

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-ge

[llvm] Use std::optional instead of Optional

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[ADT] Don't including None.h (NFC)

These source files no longer use None, so they do not need to include
None.h.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://

[ADT] Don't including None.h (NFC)

These source files no longer use None, so they do not need to include
None.h.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[llvm] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of ma

[llvm] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[llvm] Use std::size (NFC)

std::size, introduced in C++17, allows us to directly obtain the
number of elements of an array.

Support: Use Expected<T>::moveInto() in a few places

These are some usage examples for `Expected<T>::moveInto()`.

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

Fixed some errors detected by PVS Studio

[lib/Object, tools] - Make ELFObjectFile::getELFFile return reference.

We always have an object, so we don't have to return a pointer.

Differential revision: https://reviews.llvm.org/D92560

[lib/Object] - Generalize the RelocationResolver API.

This allows to reuse the RelocationResolver from the code
that doesn't want to deal with `RelocationRef` class.

I am going to use it in llvm-re

[lib/Object] - Generalize the RelocationResolver API.

This allows to reuse the RelocationResolver from the code
that doesn't want to deal with `RelocationRef` class.

I am going to use it in llvm-readobj. See the description
of D91530 for more details.

Differential revision: https://reviews.llvm.org/D91533

show more ...

[xray] Add llvm-xray extract support for 32 bit ARM

Summary:
XRay works on 32-bit ARM but extract didn't support it.

See also another previous attempt in D77858.

Reviewers: MaskRay, dberris, johni

[xray] Add llvm-xray extract support for 32 bit ARM

Summary:
XRay works on 32-bit ARM but extract didn't support it.

See also another previous attempt in D77858.

Reviewers: MaskRay, dberris, johnislarry

Subscribers: kristof.beyls, hiraditya, danielkiss, llvm-commits

Tags: #llvm

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

show more ...

clang-format xray InstrumentationMap.cpp

[Object] Change ObjectFile::getSymbolValue() return type to Expected<uint64_t>

Summary:
In D77860, we have changed `getSymbolFlags()` return type to `Expected<uint32_t>`.
This change helps bubble th

[Object] Change ObjectFile::getSymbolValue() return type to Expected<uint64_t>

Summary:
In D77860, we have changed `getSymbolFlags()` return type to `Expected<uint32_t>`.
This change helps bubble the error further up the stack.

Reviewers: jhenderson, grimar, JDevlieghere, MaskRay

Reviewed By: jhenderson

Subscribers: hiraditya, MaskRay, rupprecht, llvm-commits

Tags: #llvm

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

show more ...

[XRay] Change Sled.Function to PC-relative for sled version 2 and make llvm-xray support sled version 2 addresses

Follow-up of D78082 and D78590.

Otherwise, because xray_instr_map is now read-only,

[XRay] Change Sled.Function to PC-relative for sled version 2 and make llvm-xray support sled version 2 addresses

Follow-up of D78082 and D78590.

Otherwise, because xray_instr_map is now read-only, the absolute
relocation used for Sled.Function will cause a text relocation.

show more ...

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3b

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.

show more ...

Remove redundant "std::move"s in return statements

[llvm-xray] Add AArch64 to llvm-xray extract

This required adding support for resolving R_AARCH64_ABS64 relocations to
get accurate addresses for function names to resolve.

Authored by: ianlevesque

[llvm-xray] Add AArch64 to llvm-xray extract

This required adding support for resolving R_AARCH64_ABS64 relocations to
get accurate addresses for function names to resolve.

Authored by: ianlevesque (Ian Levesque)
Reviewers: dberris, phosek, smeenai, tetsuo-cpp
Differential Revision: https://reviews.llvm.org/D69967

show more ...

Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return Expected<>"

Changes: no changes. A fix for the clang code will be landed right on top.

Original commit message:

SectionRef

Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return Expected<>"

Changes: no changes. A fix for the clang code will be landed right on top.

Original commit message:

SectionRef::getName() returns std::error_code now.
Returning Expected<> instead has multiple benefits.

For example, it forces user to check the error returned.
Also Expected<> may keep a valuable string error message,
what is more useful than having a error code.
(Object\invalid.test was updated to show the new messages printed.)

This patch makes a change for all users to switch to Expected<> version.

Note: in a few places the error returned was ignored before my changes.
In such places I left them ignored. My intention was to convert the interface
used, and not to improve and/or the existent users in this patch.
(Though I think this is good idea for a follow-ups to revisit such places
and either remove consumeError calls or comment each of them to clarify why
it is OK to have them).

Differential revision: https://reviews.llvm.org/D66089

llvm-svn: 368826

show more ...

Revert r368812 "[llvm/Object] - Convert SectionRef::getName() to return Expected<>"

It broke clang BB: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/16455

llvm-svn: 368813

[llvm/Object] - Convert SectionRef::getName() to return Expected<>

SectionRef::getName() returns std::error_code now.
Returning Expected<> instead has multiple benefits.

For example, it forces user

[llvm/Object] - Convert SectionRef::getName() to return Expected<>

SectionRef::getName() returns std::error_code now.
Returning Expected<> instead has multiple benefits.

For example, it forces user to check the error returned.
Also Expected<> may keep a valuable string error message,
what is more useful than having a error code.
(Object\invalid.test was updated to show the new messages printed.)

This patch makes a change for all users to switch to Expected<> version.

Note: in a few places the error returned was ignored before my changes.
In such places I left them ignored. My intention was to convert the interface
used, and not to improve and/or the existent users in this patch.
(Though I think this is good idea for a follow-ups to revisit such places
and either remove consumeError calls or comment each of them to clarify why
it is OK to have them).

Differential revision: https://reviews.llvm.org/D66089

llvm-svn: 368812

show more ...

Switch LLVM to use 64-bit offsets (2/5)

This updates all libraries and tools in LLVM Core to use 64-bit offsets
which directly or indirectly come to DataExtractor.

Differential Revision: https://re

Switch LLVM to use 64-bit offsets (2/5)

This updates all libraries and tools in LLVM Core to use 64-bit offsets
which directly or indirectly come to DataExtractor.

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

llvm-svn: 368014

show more ...

Open native file handles to avoid converting from FDs, NFC

Follow up to r365588.

llvm-svn: 365820

[Support] Move llvm::MemoryBuffer to sys::fs::file_t

Summary:
On Windows, Posix integer file descriptors are a compatibility layer
over native file handles provided by the C runtime. There is a hard

[Support] Move llvm::MemoryBuffer to sys::fs::file_t

Summary:
On Windows, Posix integer file descriptors are a compatibility layer
over native file handles provided by the C runtime. There is a hard
limit on the maximum number of file descriptors that a process can open,
and the limit is 8192. LLD typically doesn't run into this limit because
it opens input files, maps them into memory, and then immediately closes
the file descriptor. This prevents it from running out of FDs.

For various reasons, I'd like to open handles to every input file and
keep them open during linking. That requires migrating MemoryBuffer over
to taking open native file handles instead of integer FDs.

Reviewers: aganea, Bigcheese

Reviewed By: aganea

Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner

Tags: #llvm

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

llvm-svn: 365588

show more ...

Recommit [Object] Change object::SectionRef::getContents() to return Expected<StringRef>

r360876 didn't fix 2 call sites in clang.

Expected<ArrayRef<uint8_t>> may be better but use Expected<StringR

Recommit [Object] Change object::SectionRef::getContents() to return Expected<StringRef>

r360876 didn't fix 2 call sites in clang.

Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now.

Follow-up of D61781.

llvm-svn: 360892

show more ...