llvm-project.git/llvm/unittests/Object/ELFObjectFileTest.cpp, branch users/pcc/spr/elf-add-preferred-function-alignment-flag Unnamed repository; edit this file 'description' to name the repository. [llvm-objcopy][libObject] Add RISC-V big-endian support (#146913) 2025-07-17T08:36:31+00:00 Djordje Todorovic djordje.todorovic@htecgroup.com 2025-07-17T08:36:31+00:00 742147ba1bb26d7a69d4289b6ad9a07bd019a2ae Add support for big-endian RISC-V ELF files: - Add riscv32be/riscv64be target architectures to Triple - Support elf32-bigriscv and elf64-bigriscv output targets in llvm-objcopy - Update ELFObjectFile to handle BE RISC-V format strings and architecture detection - Add BE RISC-V support to RelocationResolver - Add tests for new functionality This is a subset of a bigger RISC-V big-endian support patch, containing only the llvm-objcopy and libObject changes. Other changes will be added later. 
Add support for big-endian RISC-V ELF files:
  - Add riscv32be/riscv64be target architectures to Triple
- Support elf32-bigriscv and elf64-bigriscv output targets in
llvm-objcopy
- Update ELFObjectFile to handle BE RISC-V format strings and
architecture detection
  - Add BE RISC-V support to RelocationResolver
  - Add tests for new functionality

This is a subset of a bigger RISC-V big-endian support patch, containing
only the llvm-objcopy and libObject changes. Other changes will be added
later.
 [SHT_LLVM_BB_ADDR_MAP] Remove support for versions 1 and 0 (SHT_LLVM_BB_ADDR_MAP_V0). (#146186) 2025-07-02T17:31:52+00:00 Rahman Lavaee rahmanl@google.com 2025-07-02T17:31:52+00:00 6b623a6622707ea47d84ab0069f766215a6fec44 Version 2 was added more than two years ago (https://github.com/llvm/llvm-project/commit/6015a045d768feab3bae9ad9c0c81e118df8b04a). So it should be safe to deprecate older versions. 
Version 2 was added more than two years ago
(https://github.com/llvm/llvm-project/commit/6015a045d768feab3bae9ad9c0c81e118df8b04a).
So it should be safe to deprecate older versions.
 [SHT_LLVM_BB_ADDR_MAP] Encode and decode callsite offsets in a newly-introduced SHT_LLVM_BB_ADDR_MAP version. (#144426) 2025-06-23T16:25:14+00:00 Rahman Lavaee rahmanl@google.com 2025-06-23T16:25:14+00:00 8d7a8fcc3ab9f6d4c4a7e4312876fe94ed3d6c4f Recently, we have been looking at some optimizations targeting individual calls. In particular, we plan to extend the address mapping technique to map to individual callsites. For example, in this piece of code for a basic blocks: ``` <BB>: 1200: lea 0x1(%rcx), %rdx 1204: callq foo 1209: cmpq 0x10, %rdx 120d: ja L1 ``` We want to emit 0x9 as the call site offset for `callq foo` (the offset from the block entry to right after the call), so that we know if a sampled address is before the call or after. This PR implements the decode/encode/emit capability. The Codegen change will be implemented in a later PR. 
Recently, we have been looking at some optimizations targeting
individual calls. In particular, we plan to extend the address mapping
technique to map to individual callsites. For example, in this piece of
code for a basic blocks:

```
<BB>:
1200:    lea 0x1(%rcx), %rdx
1204:    callq foo
1209:    cmpq 0x10, %rdx
120d:    ja  L1
```

We want to emit 0x9 as the call site offset for `callq foo` (the offset
from the block entry to right after the call), so that we know if a
sampled address is before the call or after.

This PR implements the decode/encode/emit capability. The Codegen change
will be implemented in a later PR.
 [NFC] Remove unused test code from ELFObjectFileTest.cpp 2025-06-16T18:27:25+00:00 Rahman Lavaee rahmanl@google.com 2025-06-16T18:27:25+00:00 00582728767599bb0e88beb96e8264dbe676da53 






[ELF] Add support for CREL to getSectionAndRelocations
2025-02-10T18:57:19+00:00

Aiden Grossman
aidengrossman@google.com

2025-02-10T18:57:19+00:00

808b1c11a26ba986a4148e10f30a5ba995766f83

This patch updates the getSectionAndRelocations function to also support
CREL relocation sections. Unit tests have been added. This patch also
updates consumers to say they explicitly do not support CREL format
relocations. Subsequent patches will make the consumers work with CREL
format relocations and also add in testing support.

Reviewers: red1bluelost, MaskRay, rlavaee

Reviewed By: MaskRay

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





This patch updates the getSectionAndRelocations function to also support
CREL relocation sections. Unit tests have been added. This patch also
updates consumers to say they explicitly do not support CREL format
relocations. Subsequent patches will make the consumers work with CREL
format relocations and also add in testing support.

Reviewers: red1bluelost, MaskRay, rlavaee

Reviewed By: MaskRay

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







[SHT_LLVM_BB_ADDR_MAP] Add an option to skip emitting bb entries (#114447)
2024-11-22T19:51:34+00:00

Lei Wang
wlei@fb.com

2024-11-22T19:51:34+00:00

cf83a7fdc2dfac8220d9923a831181dccb9f7277

Sometimes we want to use a `PgoAnalysisMap` feature that doesn't require
the BB entries info, e.g. only the `FuncEntryCount`, but the BB entries
is emitted by default, so I'm adding an option to skip the info for this
case to save the binary size(can save ~90% size of the section). For
implementation, it extends a new field(`OmitBBEntries`) in
`BBAddrMap::Features` for this and it's controlled by a switch
`--basic-block-address-map-skip-bb-entries`.

Note that this naturally supports backwards compatibility as the field
is zero for the old version, matches the decoding in the new version
llvm.




Sometimes we want to use a `PgoAnalysisMap` feature that doesn't require
the BB entries info, e.g. only the `FuncEntryCount`, but the BB entries
is emitted by default, so I'm adding an option to skip the info for this
case to save the binary size(can save ~90% size of the section). For
implementation, it extends a new field(`OmitBBEntries`) in
`BBAddrMap::Features` for this and it's controlled by a switch
`--basic-block-address-map-skip-bb-entries`.

Note that this naturally supports backwards compatibility as the field
is zero for the old version, matches the decoding in the new version
llvm.






[Object] Provide operator< for ELFSymbolRef (#89861)
2024-04-29T16:07:26+00:00

Amir Ayupov
aaupov@fb.com

2024-04-29T16:07:26+00:00

df6d2faa22bf19fb27b5c083e590d13024a8d7cd

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.




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.






[SHT_LLVM_BB_ADDR_MAP] Allow basic-block-sections and labels be used together by decoupling the handling of the two features. (#74128)
2024-02-02T01:50:46+00:00

Rahman Lavaee
rahmanl@google.com

2024-02-02T01:50:46+00:00

acec6419e811a46050b0603dfa72fc6a169aa0f7

Today `-split-machine-functions` and `-fbasic-block-sections={all,list}`
cannot be combined with `-basic-block-sections=labels` (the labels
option will be ignored).
The inconsistency comes from the way basic block address map -- the
underlying mechanism for basic block labels -- encodes basic block
addresses
(https://lists.llvm.org/pipermail/llvm-dev/2020-July/143512.html).
Specifically, basic block offsets are computed relative to the function
begin symbol. This relies on functions being contiguous which is not the
case for MFS and basic block section binaries. This means Propeller
cannot use binary profiles collected from these binaries, which limits
the applicability of Propeller for iterative optimization.
    
To make the `SHT_LLVM_BB_ADDR_MAP` feature work with basic block section
binaries, we propose modifying the encoding of this section as follows.

First let us review the current encoding which emits the address of each
function and its number of basic blocks, followed by basic block entries
for each basic block.

| | |
|--|--|
| Address of the function | Function Address |
|  Number of basic blocks in this function | NumBlocks |
|  BB entry 1
|  BB entry 2
|   ...
|  BB entry #NumBlocks
    
To make this work for basic block sections, we treat each basic block
section similar to a function, except that basic block sections of the
same function must be encapsulated in the same structure so we can map
all of them to their single function.
    
We modify the encoding to first emit the number of basic block sections
(BB ranges) in the function. Then we emit the address map of each basic
block section section as before: the base address of the section, its
number of blocks, and BB entries for its basic block. The first section
in the BB address map is always the function entry section.
| | |
|--|--|
|  Number of sections for this function   | NumBBRanges |
| Section 1 begin address                     | BaseAddress[1]  |
| Number of basic blocks in section 1 | NumBlocks[1]    |
| BB entries for Section 1
|..................|
| Section #NumBBRanges begin address | BaseAddress[NumBBRanges] |
| Number of basic blocks in section #NumBBRanges |
NumBlocks[NumBBRanges] |
| BB entries for Section #NumBBRanges
    
The encoding of basic block entries remains as before with the minor
change that each basic block offset is now computed relative to the
begin symbol of its containing BB section.
    
This patch adds a new boolean codegen option `-basic-block-address-map`.
Correspondingly, the front-end flag `-fbasic-block-address-map` and LLD
flag `--lto-basic-block-address-map` are introduced.
Analogously, we add a new TargetOption field `BBAddrMap`. This means BB
address maps are either generated for all functions in the compiling
unit, or for none (depending on `TargetOptions::BBAddrMap`).
    
This patch keeps the functionality of the old
`-fbasic-block-sections=labels` option but does not remove it. A
subsequent patch will remove the obsolete option.

We refactor the `BasicBlockSections` pass by separating the BB address
map and BB sections handing to their own functions (named
`handleBBAddrMap` and `handleBBSections`). `handleBBSections` renumbers
basic blocks and places them in their assigned sections.
`handleBBAddrMap` is invoked after `handleBBSections` (if requested) and
only renumbers the blocks.
  - New tests added:
- Two tests basic-block-address-map-with-basic-block-sections.ll and
basic-block-address-map-with-mfs.ll to exercise the combination of
`-basic-block-address-map` with `-basic-block-sections=list` and
'-split-machine-functions`.
- A driver sanity test for the `-fbasic-block-address-map` option
(basic-block-address-map.c).
- An LLD test for testing the `--lto-basic-block-address-map` option.
This reuses the LLVM IR from `lld/test/ELF/lto/basic-block-sections.ll`.
- Renamed and modified the two existing codegen tests for basic block
address map (`basic-block-sections-labels-functions-sections.ll` and
`basic-block-sections-labels.ll`)
- Removed `SHT_LLVM_BB_ADDR_MAP_V0` tests. Full deprecation of
`SHT_LLVM_BB_ADDR_MAP_V0` and `SHT_LLVM_BB_ADDR_MAP` version less than 2
will happen in a separate PR in a few months.




Today `-split-machine-functions` and `-fbasic-block-sections={all,list}`
cannot be combined with `-basic-block-sections=labels` (the labels
option will be ignored).
The inconsistency comes from the way basic block address map -- the
underlying mechanism for basic block labels -- encodes basic block
addresses
(https://lists.llvm.org/pipermail/llvm-dev/2020-July/143512.html).
Specifically, basic block offsets are computed relative to the function
begin symbol. This relies on functions being contiguous which is not the
case for MFS and basic block section binaries. This means Propeller
cannot use binary profiles collected from these binaries, which limits
the applicability of Propeller for iterative optimization.
    
To make the `SHT_LLVM_BB_ADDR_MAP` feature work with basic block section
binaries, we propose modifying the encoding of this section as follows.

First let us review the current encoding which emits the address of each
function and its number of basic blocks, followed by basic block entries
for each basic block.

| | |
|--|--|
| Address of the function | Function Address |
|  Number of basic blocks in this function | NumBlocks |
|  BB entry 1
|  BB entry 2
|   ...
|  BB entry #NumBlocks
    
To make this work for basic block sections, we treat each basic block
section similar to a function, except that basic block sections of the
same function must be encapsulated in the same structure so we can map
all of them to their single function.
    
We modify the encoding to first emit the number of basic block sections
(BB ranges) in the function. Then we emit the address map of each basic
block section section as before: the base address of the section, its
number of blocks, and BB entries for its basic block. The first section
in the BB address map is always the function entry section.
| | |
|--|--|
|  Number of sections for this function   | NumBBRanges |
| Section 1 begin address                     | BaseAddress[1]  |
| Number of basic blocks in section 1 | NumBlocks[1]    |
| BB entries for Section 1
|..................|
| Section #NumBBRanges begin address | BaseAddress[NumBBRanges] |
| Number of basic blocks in section #NumBBRanges |
NumBlocks[NumBBRanges] |
| BB entries for Section #NumBBRanges
    
The encoding of basic block entries remains as before with the minor
change that each basic block offset is now computed relative to the
begin symbol of its containing BB section.
    
This patch adds a new boolean codegen option `-basic-block-address-map`.
Correspondingly, the front-end flag `-fbasic-block-address-map` and LLD
flag `--lto-basic-block-address-map` are introduced.
Analogously, we add a new TargetOption field `BBAddrMap`. This means BB
address maps are either generated for all functions in the compiling
unit, or for none (depending on `TargetOptions::BBAddrMap`).
    
This patch keeps the functionality of the old
`-fbasic-block-sections=labels` option but does not remove it. A
subsequent patch will remove the obsolete option.

We refactor the `BasicBlockSections` pass by separating the BB address
map and BB sections handing to their own functions (named
`handleBBAddrMap` and `handleBBSections`). `handleBBSections` renumbers
basic blocks and places them in their assigned sections.
`handleBBAddrMap` is invoked after `handleBBSections` (if requested) and
only renumbers the blocks.
  - New tests added:
- Two tests basic-block-address-map-with-basic-block-sections.ll and
basic-block-address-map-with-mfs.ll to exercise the combination of
`-basic-block-address-map` with `-basic-block-sections=list` and
'-split-machine-functions`.
- A driver sanity test for the `-fbasic-block-address-map` option
(basic-block-address-map.c).
- An LLD test for testing the `--lto-basic-block-address-map` option.
This reuses the LLVM IR from `lld/test/ELF/lto/basic-block-sections.ll`.
- Renamed and modified the two existing codegen tests for basic block
address map (`basic-block-sections-labels-functions-sections.ll` and
`basic-block-sections-labels.ll`)
- Removed `SHT_LLVM_BB_ADDR_MAP_V0` tests. Full deprecation of
`SHT_LLVM_BB_ADDR_MAP_V0` and `SHT_LLVM_BB_ADDR_MAP` version less than 2
will happen in a separate PR in a few months.






[SHT_LLVM_BB_ADDR_MAP] Avoids side-effects in addition since order is unspecified. (#79168)
2024-01-24T22:26:48+00:00

Micah Weston
micahsweston@gmail.com

2024-01-24T22:26:48+00:00

23faa81d3f0b701aec3731a7fce4d65c57a752b9

Turns out the problem with
https://github.com/llvm/llvm-project/issues/60013 is due to the fact
that order of operation is unspecified in C++:
https://en.cppreference.com/w/cpp/language/eval_order. A small example
of where this manifests with MSVC can be seen here
https://ooo.godbolt.org/z/bxqKeqzqn.

This patch does the following:
* Removes the addition operations where we sequence more than one
side-effect based expression.
* Removes test guards to now run on Windows




Turns out the problem with
https://github.com/llvm/llvm-project/issues/60013 is due to the fact
that order of operation is unspecified in C++:
https://en.cppreference.com/w/cpp/language/eval_order. A small example
of where this manifests with MSVC can be seen here
https://ooo.godbolt.org/z/bxqKeqzqn.

This patch does the following:
* Removes the addition operations where we sequence more than one
side-effect based expression.
* Removes test guards to now run on Windows






[SHT_LLVM_BB_ADDR_MAP,NFC] Add SCOPED_TRACE for convenient mapping of failures to test cases. (#78335)
2024-01-16T22:17:10+00:00

Rahman Lavaee
rahmanl@google.com

2024-01-16T22:17:10+00:00

6ba2c2bb804532e97180d548957bb231d994c8ff

Although parameterized gtests are preferred for this, our tests are not
very straightforward. So I decided to add SCOPED_TRACE for different
test cases and the lambda checks as well.

Typical test failure message now looks like:

```
...llvm-project/llvm/unittests/Object/ELFObjectFileTest.cpp:737
Expected equality of these values:
  *BBAddrMaps
    Which is: { 32-byte object <11-11 01-00 00-00 00-00 C0-A9 FB-3E E4-55 00-00 D0-A9 FB-3E E4-55 00-00 D0-A9 FB-3E E4-55 00-00>, 32-byte object <22-22 02-00 00-00 00-00 F0-8E FB-3E E4-55 00-00 00-8F FB-3E E4-55 00-00 00-8F FB-3E E4-55 00-00> }
  ExpectedResult
    Which is: { 32-byte object <33-33 03-00 00-00 00-00 50-A7 FB-3E E4-55 00-00 60-A7 FB-3E E4-55 00-00 60-A7 FB-3E E4-55 00-00> }
Google Test trace:
...llvm-project/llvm/unittests/Object/ELFObjectFileTest.cpp:726: for TextSectionIndex: 1 and object yaml:

--- !ELF
FileHeader:
  Class: ELFCLASS64
  Data:  ELFDATA2LSB
  Type:  ET_EXEC
Sections:
  - Name: .llvm_bb_addr_map_1
    Type: SHT_LLVM_BB_ADDR_MAP
    Link: 1
    Entries:
      - Version: 2
        Address: 0x11111
        BBEntries:
          - ID:            1
            AddressOffset: 0x0
            Size:          0x1
            Metadata:      0x2
  - Name: .llvm_bb_addr_map_2
    Type: SHT_LLVM_BB_ADDR_MAP
    Link: 1
    Entries:
      - Version: 2
        Address: 0x22222
        BBEntries:
          - ID:            2
            AddressOffset: 0x0
            Size:          0x2
            Metadata:      0x4
  - Name: .llvm_bb_addr_map_3
    Type: SHT_LLVM_BB_ADDR_MAP
    Link: 2
    Entries:
      - Version: 1
        Address: 0x33333
        BBEntries:
          - ID:            0
            AddressOffset: 0x0
            Size:          0x3
            Metadata:      0x6
  - Name: .llvm_bb_addr_map_4
    Type: SHT_LLVM_BB_ADDR_MAP_V0
  # Link: 0 (by default, can be overriden)
    Entries:
      - Version: 0
        Address: 0x44444
        BBEntries:
          - ID:            0
            AddressOffset: 0x0
            Size:          0x4
            Metadata:      0x18

...llvm-project/llvm/unittests/Object/ELFObjectFileTest.cpp:757: normal sections
```




Although parameterized gtests are preferred for this, our tests are not
very straightforward. So I decided to add SCOPED_TRACE for different
test cases and the lambda checks as well.

Typical test failure message now looks like:

```
...llvm-project/llvm/unittests/Object/ELFObjectFileTest.cpp:737
Expected equality of these values:
  *BBAddrMaps
    Which is: { 32-byte object <11-11 01-00 00-00 00-00 C0-A9 FB-3E E4-55 00-00 D0-A9 FB-3E E4-55 00-00 D0-A9 FB-3E E4-55 00-00>, 32-byte object <22-22 02-00 00-00 00-00 F0-8E FB-3E E4-55 00-00 00-8F FB-3E E4-55 00-00 00-8F FB-3E E4-55 00-00> }
  ExpectedResult
    Which is: { 32-byte object <33-33 03-00 00-00 00-00 50-A7 FB-3E E4-55 00-00 60-A7 FB-3E E4-55 00-00 60-A7 FB-3E E4-55 00-00> }
Google Test trace:
...llvm-project/llvm/unittests/Object/ELFObjectFileTest.cpp:726: for TextSectionIndex: 1 and object yaml:

--- !ELF
FileHeader:
  Class: ELFCLASS64
  Data:  ELFDATA2LSB
  Type:  ET_EXEC
Sections:
  - Name: .llvm_bb_addr_map_1
    Type: SHT_LLVM_BB_ADDR_MAP
    Link: 1
    Entries:
      - Version: 2
        Address: 0x11111
        BBEntries:
          - ID:            1
            AddressOffset: 0x0
            Size:          0x1
            Metadata:      0x2
  - Name: .llvm_bb_addr_map_2
    Type: SHT_LLVM_BB_ADDR_MAP
    Link: 1
    Entries:
      - Version: 2
        Address: 0x22222
        BBEntries:
          - ID:            2
            AddressOffset: 0x0
            Size:          0x2
            Metadata:      0x4
  - Name: .llvm_bb_addr_map_3
    Type: SHT_LLVM_BB_ADDR_MAP
    Link: 2
    Entries:
      - Version: 1
        Address: 0x33333
        BBEntries:
          - ID:            0
            AddressOffset: 0x0
            Size:          0x3
            Metadata:      0x6
  - Name: .llvm_bb_addr_map_4
    Type: SHT_LLVM_BB_ADDR_MAP_V0
  # Link: 0 (by default, can be overriden)
    Entries:
      - Version: 0
        Address: 0x44444
        BBEntries:
          - ID:            0
            AddressOffset: 0x0
            Size:          0x4
            Metadata:      0x18

...llvm-project/llvm/unittests/Object/ELFObjectFileTest.cpp:757: normal sections
```