Lines Matching +full:- +full:section

1 .. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)
12 LLVM BPF backend records each relocation with the following 16-byte
17     Elf64_Addr    r_offset;  // Offset from the beginning of section.
23   int g1 __attribute__((section("sec")));
24   int g2 __attribute__((section("sec")));
25   static volatile int l1 __attribute__((section("sec")));
26   static volatile int l2 __attribute__((section("sec")));
31 Compiled with ``clang -target bpf -O2 -c test.c``, the following is
32 the code with ``llvm-objdump -dr test.o``::
52 The following ``llvm-readelf -r test.o`` shows the binary values of the four
55   Relocation section '.rel.text' at offset 0x190 contains 4 entries:
66 The following is the symbol table with ``llvm-readelf -s test.o``::
74        4: 0000000000000000     0 SECTION LOCAL  DEFAULT     4 sec
83 from the start of ``.data`` section.
86 and ``l2``. From ``.rel.text`` section above, it is not clear
89 and represents a section. So for static variable or function,
90 the section offset is written to the original insn
92 above insn ``7`` and ``11``, they have section offset ``8`` and ``12``.
97 and is the section offset or some computation result based on
98 section offset for static variables/functions. The non-section-offset
113   10    R_BPF_64_32        call insn        32       r_offset + 4  (S + A) / 8 - 1
116 The actual to-be-relocated data (0 or section offset)
120 means the section offset must be less than or equal to ``UINT32_MAX`` and this
123 In another case, ``R_BPF_64_ABS64`` relocation type is used for normal 64-bit data.
124 The actual to-be-relocated data is stored at ``r_offset`` and the read/write data
128 Both ``R_BPF_64_ABS32`` and ``R_BPF_64_NODYLD32`` types are for 32-bit data.
135 Type ``R_BPF_64_32`` is used for call instruction. The call target section
137 ``(S + A) / 8 - 1``.
145   __attribute__((noinline)) __attribute__((section("sec1")))
149   static __attribute__((noinline)) __attribute__((section("sec1")))
153   int global __attribute__((section("sec2")));
158 Compiled with ``clang -target bpf -O2 -c test.c``, we will have
159 following code with `llvm-objdump -dr test.o``::
161   Disassembly of section .text:
166          2:       85 10 00 00 ff ff ff ff call -1
180   Disassembly of section sec1:
193 so the ``call`` instruction offset is ``(0 + 0)/8 - 1 = -1``.
194 The second relocation corresponds to ``lfunc(a, b)`` where ``lfunc`` has a section
195 offset ``0x18``, so the ``call`` instruction offset is ``(0 + 0x18)/8 - 1 = 2``.
196 The third relocation corresponds to ld_imm64 of ``global``, which has a section
204 Compiled with ``clang -target bpf -O2 -g -c test.c``, we will see a
205 relocation below in ``.data`` section with command
206 ``llvm-readelf -r test.o``::
208   Relocation section '.rel.data' at offset 0x458 contains 1 entries:
212 The relocation says the first 8-byte of ``.data`` section should be
215 With ``llvm-readelf`` output, we can see that dwarf sections have a bunch of
218   Relocation section '.rel.debug_info' at offset 0x468 contains 13 entries:
233   Relocation section '.rel.BTF' at offset 0x538 contains 1 entries:
237   Relocation section '.rel.BTF.ext' at offset 0x548 contains 2 entries: