History log of /llvm-project/llvm/unittests/DebugInfo/BTF/BTFParserTest.cpp (Results 1 – 5 of 5)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 75bc20ff 06-Jul-2024 Kazu Hirata <kazu@google.com>

[llvm] Remove redundant calls to std::unique_ptr<T>::get (NFC) (#97914)


Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4
# d15f96fe 07-May-2023 Eduard Zingerman <eddyz87@gmail.com>

[BPF][DebugInfo] Show CO-RE relocations in llvm-objdump

Extend llvm-objdump to show CO-RE relocations when `-r` option is
passed and object file has .BTF and .BTF.ext sections.

For example, the fol

[BPF][DebugInfo] Show CO-RE relocations in llvm-objdump

Extend llvm-objdump to show CO-RE relocations when `-r` option is
passed and object file has .BTF and .BTF.ext sections.

For example, the following C program:

#define __pai __attribute__((preserve_access_index))

struct foo { int i; int j;} __pai;
struct bar { struct foo f[7]; } __pai;
extern void sink(void *);

void root(struct bar *bar) {
sink(&bar[2].f[3].j);
}

Should lead to the following objdump output:

$ clang --target=bpf -O2 -g t.c -c -o - | \
llvm-objdump --no-addresses --no-show-raw-insn -dr -

...
r2 = 0x94
CO-RE <byte_off> [2] struct bar::[2].f[3].j (2:0:3:1)
r1 += r2
call -0x1
R_BPF_64_32 sink
exit
...

More examples could be found in unit tests, see BTFParserTest.cpp.

To achieve this:
- Move CO-RE relocation kinds definitions from BPFCORE.h to BTF.h.
- Extend BTF.h with types derived from BTF::CommonType, e.g.
BTF::IntType and BTF::StrutType, to allow dyn_cast() and access to
type additional data.
- Extend BTFParser to load BTF type and relocation data.
- Modify llvm-objdump.cpp to create instance of BTFParser when
disassembly of object file with BTF sections is processed and `-r`
flag is supplied.

Additional information about CO-RE is available at [1].

[1] https://docs.kernel.org/bpf/llvm_reloc.html

Depends on D149058

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

show more ...


# 490e8e22 13-Jul-2023 Eduard Zingerman <eddyz87@gmail.com>

[BTF] Fix BTFParserTest.cpp for unaligned access after D149058

Test bot reported an issue with unit tests for D149058 in [1]:

[==========] Running 1 test from 1 test suite.
[----------] Global

[BTF] Fix BTFParserTest.cpp for unaligned access after D149058

Test bot reported an issue with unit tests for D149058 in [1]:

[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from BTFParserTest
[ RUN ] BTFParserTest.simpleCorrectInput
/b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/unittests/DebugInfo/BTF/BTFParserTest.cpp:141:33:
runtime error: upcast of misaligned address 0x7facce60411f for type 'llvm::SmallString<0>', which requires 8 byte alignment
0x7facce60411f: note: pointer points here
64 00 00 00 37 41 60 ce ac 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
/b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/unittests/DebugInfo/BTF/BTFParserTest.cpp:141:33

The issue is caused by attribute "packed" used for too many things:

#pragma pack(push, 1)
struct MockData1 {
struct B {
...
} BTF;
struct E {
...
} Ext;

int BTFSectionLen = sizeof(BTF);
int ExtSectionLen = sizeof(Ext);

SmallString<0> Storage;
std::unique_ptr<ObjectFile> Obj;

}
#pragma pack(pop)

Access to unaligned pointers in `Storage`/`Obj` causes unaligned
access errors.

To fix this #pragma directives are pushed invards to apply only to `B`
and `E` definitions.

[1] https://lab.llvm.org/buildbot/#/builders/5/builds/35040

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

show more ...


# 8130166b 12-Jul-2023 Fangrui Song <i@maskray.me>

[BTF] Fix BTFParserTest.cpp for big-endian after D149058

Ideally BTFParserTest.cpp should test both little-endian and big-endian, but I
push this commit to fix the immediate issue for now.


# c8e055d4 12-Jul-2023 Eduard Zingerman <eddyz87@gmail.com>

[BPF][DebugInfo] Use .BPF.ext for line info when DWARF is not available

"BTF" is a debug information format used by LLVM's BPF backend.
The format is much smaller in scope than DWARF, the following

[BPF][DebugInfo] Use .BPF.ext for line info when DWARF is not available

"BTF" is a debug information format used by LLVM's BPF backend.
The format is much smaller in scope than DWARF, the following info is
available:
- full set of C types used in the binary file;
- types for global values;
- line number / line source code information .

BTF information is embedded in ELF as .BTF and .BTF.ext sections.
Detailed format description could be found as a part of Linux Source
tree, e.g. here: [1].

This commit modifies `llvm-objdump` utility to use line number
information provided by BTF if DWARF information is not available.
E.g., the goal is to make the following to print source code lines,
interleaved with disassembly:

$ clang --target=bpf -g test.c -o test.o
$ llvm-strip --strip-debug test.o
$ llvm-objdump -Sd test.o

test.o: file format elf64-bpf

Disassembly of section .text:

<foo>:
; void foo(void) {
r1 = 0x1
; consume(1);
call -0x1
r1 = 0x2
; consume(2);
call -0x1
; }
exit

A common production use case for BPF programs is to:
- compile separate object files using clang with `-g -c` flags;
- link these files as a final "static" binary using bpftool linker ([2]).
The bpftool linker discards most of the DWARF sections
(line information sections as well) but merges .BTF and .BTF.ext sections.
Hence, having `llvm-objdump` capable to print source code using .BTF.ext
is valuable.

The commit consists of the following modifications:

- llvm/lib/DebugInfo/BTF aka `DebugInfoBTF` component is added to host
the code needed to process BTF (with assumption that BTF support
would be added to some other tools as well, e.g. `llvm-readelf`):
- `DebugInfoBTF` provides `llvm::BTFParser` class, that loads information
from `.BTF` and `.BTF.ext` sections of a given `object::ObjectFile`
instance and allows to query this information.
Currently only line number information is loaded.

- `DebugInfoBTF` also provides `llvm::BTFContext` class, which is an
implementation of `DIContext` interface, used by `llvm-objdump` to
query information about line numbers corresponding to specific
instructions.

- Structure `DILineInfo` is modified with field `LineSource`.

`DIContext` interface uses `DILineInfo` structure to communicate
line number and source code information.
Specifically, `DILineInfo::Source` field encodes full file source code,
if available. BTF only stores source code for selected lines of the
file, not a complete source file. Moreover, stored lines are not
guaranteed to be sorted in a specific order.

To avoid reconstruction of a file source code from a set of
available lines, this commit adds `LineSource` field instead.

- `Symbolize` class is modified to use `BTFContext` instead of
`DWARFContext` when DWARF sections are not available but BTF
sections are present in the object file.
(`Symbolize` is instantiated by `llvm-objdump`).

- Integration and unit tests.

Note, that DWARF has a notion of "instruction sequence".
DWARF implementation of `DIContext::getLineInfoForAddress()` provides
inexact responses if exact address information is not available but
address falls within "instruction sequence" with some known line
information (see `DWARFDebugLine::LineTable::findRowInSeq()`).

BTF does not provide instruction sequence groupings, thus
`getLineInfoForAddress()` queries only return exact matches.
This does not seem to be a big issue in practice, but output
of the `llvm-objdump -Sd` might differ slightly when BTF
is used instead of DWARF.

[1] https://www.kernel.org/doc/html/latest/bpf/btf.html
[2] https://github.com/libbpf/bpftool

Depends on https://reviews.llvm.org/D149501

Reviewed By: MaskRay, yonghong-song, nickdesaulniers, #debug-info

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

show more ...