[Object] Refine isData/isBSS criteria

In GNU, DATA applies to not only SHT_PROGBITS, but also other non-NOBITS
types. BSS doesn't require the SHF_WRITE flag.

Pull Request: https://github.com/llvm/l

[Object] Refine isData/isBSS criteria

In GNU, DATA applies to not only SHT_PROGBITS, but also other non-NOBITS
types. BSS doesn't require the SHF_WRITE flag.

Pull Request: https://github.com/llvm/llvm-project/pull/101290

show more ...

[llvm-objdump] -r: support CREL

Extract the llvm-readelf decoder to `decodeCrel` (#91280) and reuse it
for llvm-objdump.

Because the section representation of LLVMObject (`SectionRef`) is
64-bit, i

[llvm-objdump] -r: support CREL

Extract the llvm-readelf decoder to `decodeCrel` (#91280) and reuse it
for llvm-objdump.

Because the section representation of LLVMObject (`SectionRef`) is
64-bit, insufficient to hold all decoder states, `section_rel_begin` is
modified to decode CREL eagerly and hold the decoded relocations inside
ELFObjectFile<ELFT>.

The test is adapted from llvm/test/tools/llvm-readobj/ELF/crel.test.

Pull Request: https://github.com/llvm/llvm-project/pull/97382

show more ...

[Object] Provide operator< for ELFSymbolRef (#89861)

Normally, operator< accepting DataRefImpl is used when comparing
SymbolRef/ELFSymbolRef. However, it uses std::memcmp which interprets
DataRefI

[Object] Provide operator< for ELFSymbolRef (#89861)

Normally, operator< accepting DataRefImpl is used when comparing
SymbolRef/ELFSymbolRef. However, it uses std::memcmp which interprets
DataRefImpl union as char string so that the result depends on host
endianness.
For ELFSymbolRef a specialized operator< can be used instead to produce
consistent ordering regardless of endianness by comparing the symbol
table index and symbol index fields separately.

show more ...

[MC] Rename temporary symbols of empty name to ".L0 " (#89693)

Temporary symbols generated for .eh_frame and .debug_line have an empty
name, which appear in .symtab in the presence of RISC-V style l

[MC] Rename temporary symbols of empty name to ".L0 " (#89693)

Temporary symbols generated for .eh_frame and .debug_line have an empty
name, which appear in .symtab in the presence of RISC-V style linker
relaxation and will not be discarded by ld/objcopy --discard-locals
(-X).

In contrast, GNU assembler's riscv port assigns a fake name ".L0 " (with
a trailing space) to these symbols so that will be discarded by
ld/objcopy --discard-locals.

This patch matches the GNU behavior. Since Clang's RISC-V targets pass
-X to ld, and GNU ld defaults to -X for RISC-V targets, these ".L0 "
symbols will be discarded after linking by default, as expected by
users.

The llvm-symbolizer special case for RISC-V `SF_FormatSpecific` symbols
https://reviews.llvm.org/D98669 needs to be adjusted.

Note: `"":` in assembly currently crashes.

Note: bolt tests used /usr/bin/clang before
llvmorg-19-init-9532-g59bfc3106874.
The revert llvmorg-19-init-9531-g28b55342e1a8 actually broke
bolt/test/RISCV/fake-label-no-entry.c

show more ...

Revert "[MC] Rename temporary symbols of empty name to ".L0 " (#89693)"

This reverts commit 96c45a7fa12619c3abd6b81effe4c80f0916b78b.

Broke BOLT builders and all pre-merge testing:
https://lab.llvm

Revert "[MC] Rename temporary symbols of empty name to ".L0 " (#89693)"

This reverts commit 96c45a7fa12619c3abd6b81effe4c80f0916b78b.

Broke BOLT builders and all pre-merge testing:
https://lab.llvm.org/buildbot/#/builders/244/builds/28097

show more ...

[MC] Rename temporary symbols of empty name to ".L0 " (#89693)

Temporary symbols generated for .eh_frame and .debug_line have an empty
name, which appear in .symtab in the presence of RISC-V style l

[MC] Rename temporary symbols of empty name to ".L0 " (#89693)

Temporary symbols generated for .eh_frame and .debug_line have an empty
name, which appear in .symtab in the presence of RISC-V style linker
relaxation and will not be discarded by ld/objcopy --discard-locals
(-X).

In contrast, GNU assembler's riscv port assigns a fake name ".L0 " (with
a trailing space) to these symbols so that will be discarded by
ld/objcopy --discard-locals.

This patch matches the GNU behavior. Since Clang's RISC-V targets pass
-X to ld, and GNU ld defaults to -X for RISC-V targets, these ".L0 "
symbols will be discarded after linking by default, as expected by
users.

The llvm-symbolizer special case for RISC-V `SF_FormatSpecific` symbols
https://reviews.llvm.org/D98669 needs to be adjusted.

Note: `"":` in assembly currently crashes.

show more ...

Revert "[MC] Rename temporary symbols of empty name to ".L0 "" (#90002)

Reverts llvm/llvm-project#89693

This broke the premerge bot (bolt tests failing)

[MC] Rename temporary symbols of empty name to ".L0 " (#89693)

Temporary symbols generated for .eh_frame and .debug_line have an empty
name, which appear in .symtab in the presence of RISC-V style

[MC] Rename temporary symbols of empty name to ".L0 " (#89693)

Temporary symbols generated for .eh_frame and .debug_line have an empty
name, which appear in .symtab in the presence of RISC-V style linker
relaxation and will not be discarded by ld/objcopy --discard-locals
(-X).

In contrast, GNU assembler's riscv port assigns a fake name ".L0 " (with
a trailing space) to these symbols so that will be discarded by
ld/objcopy --discard-locals.

This patch matches the GNU behavior. Since Clang's RISC-V targets pass
-X to ld, and GNU ld defaults to -X for RISC-V targets, these ".L0 "
symbols will be discarded after linking by default, as expected by
users.

The llvm-symbolizer special case for RISC-V `SF_FormatSpecific` symbols
https://reviews.llvm.org/D98669 needs to be adjusted.

Note: `"":` in assembly currently crashes.

show more ...

[Object,ELFType] Rename TargetEndianness to Endianness (#86604)

`TargetEndianness` is long and unwieldy. "Target" in the name is confusing. Rename it to "Endianness".

I cannot find noticeable out

[Object,ELFType] Rename TargetEndianness to Endianness (#86604)

`TargetEndianness` is long and unwieldy. "Target" in the name is confusing. Rename it to "Endianness".

I cannot find noticeable out-of-tree users of `TargetEndianness`, but
keep `TargetEndianness` to make this patch safer. `TargetEndianness`
will be removed by a subsequent change.

show more ...

[Hexagon] ELF attributes for Hexagon (#85359)

Defines a subset of attributes and emits them to a section called
.hexagon.attributes.

The current attributes recorded are the attributes needed by

[Hexagon] ELF attributes for Hexagon (#85359)

Defines a subset of attributes and emits them to a section called
.hexagon.attributes.

The current attributes recorded are the attributes needed by
llvm-objdump to automatically determine target features and eliminate
the need to manually pass features.

show more ...

[Object] getBuildAttributes: check e_machine. NFC

getBuildAttributes is only called for ARM/RISCV object files and
`SHT_ARM_ATTRIBUTES == SHT_RISCV_ATTRIBUTES`, so the following check
`Sec.sh_type =

[Object] getBuildAttributes: check e_machine. NFC

getBuildAttributes is only called for ARM/RISCV object files and
`SHT_ARM_ATTRIBUTES == SHT_RISCV_ATTRIBUTES`, so the following check
`Sec.sh_type == ELF::SHT_ARM_ATTRIBUTES || Sec.sh_type == ELF::SHT_RISCV_ATTRIBUTES`
is actually fine. But the convention is to guard such processor-specific
section type checks with an e_machine test.

show more ...

[llvm-objdump][AMDGPU] Pass ELF ABIVersion through disassembler (#78907)

Admittedly, its a bit ugly to pass the ABIVersion through onSymbolStart
but I'm not sure what a better place for it would be.

[SHT_LLVM_BB_ADDR_MAP] Add assertion and clarify docstring (#77374)

This patch adds an assertion to readBBAddrMapImpl to confirm that
PGOAnalyses and BBAddrMaps are of the same size when PGO inform

[SHT_LLVM_BB_ADDR_MAP] Add assertion and clarify docstring (#77374)

This patch adds an assertion to readBBAddrMapImpl to confirm that
PGOAnalyses and BBAddrMaps are of the same size when PGO information is
requested (part of the API contract). This patch also updates the
docstring for readBBAddrMap to better clarify what is guaranteed.

show more ...

[ELF] Again attempt to fix test on BE architectures

Summary:
This formats something according to the style, and again attempts to fix
this failing on the BE PPC test. Sorry for the spam, these commi

[ELF] Again attempt to fix test on BE architectures

Summary:
This formats something according to the style, and again attempts to fix
this failing on the BE PPC test. Sorry for the spam, these commits are
the only way I can check it because the failure isn't local.

show more ...

[ELF] Attempt to set the OS when using 'makeTriple()' (#76992)

Summary:
This patch fixes up the `makeTriple()` interface to emit append the
operating system information when it is readily avaialble

[ELF] Attempt to set the OS when using 'makeTriple()' (#76992)

Summary:
This patch fixes up the `makeTriple()` interface to emit append the
operating system information when it is readily avaialble from the ELF.
The main motivation for this is so the GPU architectures can be easily
identified correctly when given and ELF. E.g. we want
`amdgpu-amd-amdhsa` as the output and not `amdgpu--`.

This required adding support for the CUDA OS/ABI, which is easily found
to be `0x33` when using `readelf`.

show more ...

[ELF] Correctly set the `nvptx` triple from `makeTriple()` (#76970)

Summary:
The ELFObject file should be able to handle `nvptx` objects but we
currently list them as unknown. This patch should now

[ELF] Correctly set the `nvptx` triple from `makeTriple()` (#76970)

Summary:
The ELFObject file should be able to handle `nvptx` objects but we
currently list them as unknown. This patch should now make it return
`nvptx64--` correctly.

show more ...

[ELF] Add CPU name detection for CUDA architectures (#75964)

Summary:
Recently we added support for detecting the CUDA processor with the ELF
flags. This allows us to get a string representation of

[ELF] Add CPU name detection for CUDA architectures (#75964)

Summary:
Recently we added support for detecting the CUDA processor with the ELF
flags. This allows us to get a string representation of it in other
code. This will be used by the offloading runtime.

show more ...

[SHT_LLVM_BB_ADDR_MAP] Implements PGOAnalysisMap in Object and ObjectYAML with tests.

Reviewed in PR (#71750). A part of [RFC - PGO Accuracy Metrics: Emitting and Evaluating Branch
and Block
Analy

[SHT_LLVM_BB_ADDR_MAP] Implements PGOAnalysisMap in Object and ObjectYAML with tests.

Reviewed in PR (#71750). A part of [RFC - PGO Accuracy Metrics: Emitting and Evaluating Branch
and Block
Analysis](https://discourse.llvm.org/t/rfc-pgo-accuracy-metrics-emitting-and-evaluating-branch-and-block-analysis/73902).

This PR adds the PGOAnalysisMap data structure and implements encoding and
decoding through Object and ObjectYAML along with associated tests. When
emitted into the bb-addr-map section, each function is followed by the associated
pgo-analysis-map for that function. The emitting of each analysis in the map is
controlled by a bit in the bb-addr-map feature byte. All existing bb-addr-map
code can ignore the pgo-analysis-map if the caller does not request the data.

show more ...

[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::

[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

[llvm] Stop including llvm/Support/Endian.h (NFC)

These files do not use anything from llvm/Support/Endian.h.

Use llvm::endianness::{big,little,native} (NFC)

Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces suppo

Use llvm::endianness::{big,little,native} (NFC)

Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces support::{big,little,native} with
llvm::endianness::{big,little,native}.

show more ...

[RISCV] Make mapping symbols SF_FormatSpecific

This ensures that llvm-symbolizer ignores them for symbolization.

Note: unlike aarch64-mapping-symbol.s, the test included here does not
test if the m

[RISCV] Make mapping symbols SF_FormatSpecific

This ensures that llvm-symbolizer ignores them for symbolization.

Note: unlike aarch64-mapping-symbol.s, the test included here does not
test if the mapping symbols are actually in the symbol table. The reason
is that llvm-mc support for RISC-V mapping symbols (D153260) has not
landed yet, so the mapping symbols simply aren't there. However, D153260
would like to depend on this patch together with D156190 to avoid having
to update a large amount of tests.

Reviewed By: MaskRay

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

show more ...

[CSKY] Make mapping symbols SF_FormatSpecific

and omit them from llvm-nm output unless --special-syms is specified,
similar to ARM and AArch64.

This is a prerequisite of D156190 as llvm-objdump wil

[CSKY] Make mapping symbols SF_FormatSpecific

and omit them from llvm-nm output unless --special-syms is specified,
similar to ARM and AArch64.

This is a prerequisite of D156190 as llvm-objdump will only perform
mapping symbol recognition for SF_FormatSpecific symbols.

show more ...

[Object] fixed invalid symbol handling in ELFObjectFile::getSymbolName

Found a bug in ElfObjectFile.h that occurred when there was an invalid Symbol Name in an object file. This error affected the b

[Object] fixed invalid symbol handling in ELFObjectFile::getSymbolName

Found a bug in ElfObjectFile.h that occurred when there was an invalid Symbol Name in an object file. This error affected the behavior of the Expected<> value and leading it to abort, rather than behave as normal. I found this as I was adding tests to llvm-cm, as prompted by @jhenderson.

Without this fix, upon encountering an invalid symbol and trying tot l get its name, the program states that
```Expected<T> must be checked before access or destruction```
and aborts.

Reviewed By: MaskRay

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

show more ...

Move SubtargetFeature.h from MC to TargetParser

SubtargetFeature.h is currently part of MC while it doesn't depend on
anything in MC. Since some LLVM components might have the need to work
with targ

Move SubtargetFeature.h from MC to TargetParser

SubtargetFeature.h is currently part of MC while it doesn't depend on
anything in MC. Since some LLVM components might have the need to work
with target features without necessarily needing MC, it might be
worthwhile to move SubtargetFeature.h to a different location. This will
reduce the dependencies of said components.

Note that I choose TargetParser as the destination because that's where
Triple lives and SubtargetFeatures feels related to that.

This issues came up during a JITLink review (D149522). JITLink would
like to avoid a dependency on MC while still needing to store target
features.

Reviewed By: MaskRay, arsenm

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

show more ...