Commit | Line | Data |
---|---|---|
fc8c262e YS |
1 | .. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) |
2 | ||
3 | ==================== | |
4 | BPF LLVM Relocations | |
5 | ==================== | |
6 | ||
7 | This document describes LLVM BPF backend relocation types. | |
8 | ||
9 | Relocation Record | |
10 | ================= | |
11 | ||
12 | LLVM BPF backend records each relocation with the following 16-byte | |
13 | ELF structure:: | |
14 | ||
15 | typedef struct | |
16 | { | |
17 | Elf64_Addr r_offset; // Offset from the beginning of section. | |
18 | Elf64_Xword r_info; // Relocation type and symbol index. | |
19 | } Elf64_Rel; | |
20 | ||
21 | For example, for the following code:: | |
22 | ||
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"))); | |
27 | int test() { | |
28 | return g1 + g2 + l1 + l2; | |
29 | } | |
30 | ||
bbaf1ff0 | 31 | Compiled with ``clang --target=bpf -O2 -c test.c``, the following is |
fc8c262e YS |
32 | the code with ``llvm-objdump -dr test.o``:: |
33 | ||
34 | 0: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll | |
35 | 0000000000000000: R_BPF_64_64 g1 | |
36 | 2: 61 11 00 00 00 00 00 00 r1 = *(u32 *)(r1 + 0) | |
37 | 3: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0 ll | |
38 | 0000000000000018: R_BPF_64_64 g2 | |
39 | 5: 61 20 00 00 00 00 00 00 r0 = *(u32 *)(r2 + 0) | |
40 | 6: 0f 10 00 00 00 00 00 00 r0 += r1 | |
41 | 7: 18 01 00 00 08 00 00 00 00 00 00 00 00 00 00 00 r1 = 8 ll | |
42 | 0000000000000038: R_BPF_64_64 sec | |
43 | 9: 61 11 00 00 00 00 00 00 r1 = *(u32 *)(r1 + 0) | |
44 | 10: 0f 10 00 00 00 00 00 00 r0 += r1 | |
45 | 11: 18 01 00 00 0c 00 00 00 00 00 00 00 00 00 00 00 r1 = 12 ll | |
46 | 0000000000000058: R_BPF_64_64 sec | |
47 | 13: 61 11 00 00 00 00 00 00 r1 = *(u32 *)(r1 + 0) | |
48 | 14: 0f 10 00 00 00 00 00 00 r0 += r1 | |
49 | 15: 95 00 00 00 00 00 00 00 exit | |
50 | ||
69535186 | 51 | There are four relocations in the above for four ``LD_imm64`` instructions. |
fc8c262e YS |
52 | The following ``llvm-readelf -r test.o`` shows the binary values of the four |
53 | relocations:: | |
54 | ||
55 | Relocation section '.rel.text' at offset 0x190 contains 4 entries: | |
56 | Offset Info Type Symbol's Value Symbol's Name | |
57 | 0000000000000000 0000000600000001 R_BPF_64_64 0000000000000000 g1 | |
58 | 0000000000000018 0000000700000001 R_BPF_64_64 0000000000000004 g2 | |
59 | 0000000000000038 0000000400000001 R_BPF_64_64 0000000000000000 sec | |
60 | 0000000000000058 0000000400000001 R_BPF_64_64 0000000000000000 sec | |
61 | ||
62 | Each relocation is represented by ``Offset`` (8 bytes) and ``Info`` (8 bytes). | |
63 | For example, the first relocation corresponds to the first instruction | |
64 | (Offset 0x0) and the corresponding ``Info`` indicates the relocation type | |
65 | of ``R_BPF_64_64`` (type 1) and the entry in the symbol table (entry 6). | |
66 | The following is the symbol table with ``llvm-readelf -s test.o``:: | |
67 | ||
68 | Symbol table '.symtab' contains 8 entries: | |
69 | Num: Value Size Type Bind Vis Ndx Name | |
70 | 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND | |
71 | 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS test.c | |
72 | 2: 0000000000000008 4 OBJECT LOCAL DEFAULT 4 l1 | |
73 | 3: 000000000000000c 4 OBJECT LOCAL DEFAULT 4 l2 | |
74 | 4: 0000000000000000 0 SECTION LOCAL DEFAULT 4 sec | |
75 | 5: 0000000000000000 128 FUNC GLOBAL DEFAULT 2 test | |
76 | 6: 0000000000000000 4 OBJECT GLOBAL DEFAULT 4 g1 | |
77 | 7: 0000000000000004 4 OBJECT GLOBAL DEFAULT 4 g2 | |
78 | ||
79 | The 6th entry is global variable ``g1`` with value 0. | |
80 | ||
81 | Similarly, the second relocation is at ``.text`` offset ``0x18``, instruction 3, | |
69535186 WH |
82 | has a type of ``R_BPF_64_64`` and refers to entry 7 in the symbol table. |
83 | The second relocation resolves to global variable ``g2`` which has a symbol | |
84 | value 4. The symbol value represents the offset from the start of ``.data`` | |
85 | section where the initial value of the global variable ``g2`` is stored. | |
86 | ||
87 | The third and fourth relocations refer to static variables ``l1`` | |
88 | and ``l2``. From the ``.rel.text`` section above, it is not clear | |
89 | to which symbols they really refer as they both refer to | |
fc8c262e | 90 | symbol table entry 4, symbol ``sec``, which has ``STT_SECTION`` type |
69535186 | 91 | and represents a section. So for a static variable or function, |
fc8c262e YS |
92 | the section offset is written to the original insn |
93 | buffer, which is called ``A`` (addend). Looking at | |
94 | above insn ``7`` and ``11``, they have section offset ``8`` and ``12``. | |
95 | From symbol table, we can find that they correspond to entries ``2`` | |
96 | and ``3`` for ``l1`` and ``l2``. | |
97 | ||
98 | In general, the ``A`` is 0 for global variables and functions, | |
99 | and is the section offset or some computation result based on | |
100 | section offset for static variables/functions. The non-section-offset | |
101 | case refers to function calls. See below for more details. | |
102 | ||
103 | Different Relocation Types | |
104 | ========================== | |
105 | ||
106 | Six relocation types are supported. The following is an overview and | |
107 | ``S`` represents the value of the symbol in the symbol table:: | |
108 | ||
109 | Enum ELF Reloc Type Description BitSize Offset Calculation | |
110 | 0 R_BPF_NONE None | |
111 | 1 R_BPF_64_64 ld_imm64 insn 32 r_offset + 4 S + A | |
112 | 2 R_BPF_64_ABS64 normal data 64 r_offset S + A | |
113 | 3 R_BPF_64_ABS32 normal data 32 r_offset S + A | |
114 | 4 R_BPF_64_NODYLD32 .BTF[.ext] data 32 r_offset S + A | |
115 | 10 R_BPF_64_32 call insn 32 r_offset + 4 (S + A) / 8 - 1 | |
116 | ||
117 | For example, ``R_BPF_64_64`` relocation type is used for ``ld_imm64`` instruction. | |
118 | The actual to-be-relocated data (0 or section offset) | |
119 | is stored at ``r_offset + 4`` and the read/write | |
120 | data bitsize is 32 (4 bytes). The relocation can be resolved with | |
121 | the symbol value plus implicit addend. Note that the ``BitSize`` is 32 which | |
122 | means the section offset must be less than or equal to ``UINT32_MAX`` and this | |
123 | is enforced by LLVM BPF backend. | |
124 | ||
125 | In another case, ``R_BPF_64_ABS64`` relocation type is used for normal 64-bit data. | |
126 | The actual to-be-relocated data is stored at ``r_offset`` and the read/write data | |
127 | bitsize is 64 (8 bytes). The relocation can be resolved with | |
128 | the symbol value plus implicit addend. | |
129 | ||
130 | Both ``R_BPF_64_ABS32`` and ``R_BPF_64_NODYLD32`` types are for 32-bit data. | |
131 | But ``R_BPF_64_NODYLD32`` specifically refers to relocations in ``.BTF`` and | |
132 | ``.BTF.ext`` sections. For cases like bcc where llvm ``ExecutionEngine RuntimeDyld`` | |
133 | is involved, ``R_BPF_64_NODYLD32`` types of relocations should not be resolved | |
134 | to actual function/variable address. Otherwise, ``.BTF`` and ``.BTF.ext`` | |
135 | become unusable by bcc and kernel. | |
136 | ||
137 | Type ``R_BPF_64_32`` is used for call instruction. The call target section | |
138 | offset is stored at ``r_offset + 4`` (32bit) and calculated as | |
139 | ``(S + A) / 8 - 1``. | |
140 | ||
141 | Examples | |
142 | ======== | |
143 | ||
144 | Types ``R_BPF_64_64`` and ``R_BPF_64_32`` are used to resolve ``ld_imm64`` | |
145 | and ``call`` instructions. For example:: | |
146 | ||
147 | __attribute__((noinline)) __attribute__((section("sec1"))) | |
148 | int gfunc(int a, int b) { | |
149 | return a * b; | |
150 | } | |
151 | static __attribute__((noinline)) __attribute__((section("sec1"))) | |
152 | int lfunc(int a, int b) { | |
153 | return a + b; | |
154 | } | |
155 | int global __attribute__((section("sec2"))); | |
156 | int test(int a, int b) { | |
157 | return gfunc(a, b) + lfunc(a, b) + global; | |
158 | } | |
159 | ||
bbaf1ff0 | 160 | Compiled with ``clang --target=bpf -O2 -c test.c``, we will have |
fc8c262e YS |
161 | following code with `llvm-objdump -dr test.o``:: |
162 | ||
163 | Disassembly of section .text: | |
164 | ||
165 | 0000000000000000 <test>: | |
166 | 0: bf 26 00 00 00 00 00 00 r6 = r2 | |
167 | 1: bf 17 00 00 00 00 00 00 r7 = r1 | |
168 | 2: 85 10 00 00 ff ff ff ff call -1 | |
169 | 0000000000000010: R_BPF_64_32 gfunc | |
170 | 3: bf 08 00 00 00 00 00 00 r8 = r0 | |
171 | 4: bf 71 00 00 00 00 00 00 r1 = r7 | |
172 | 5: bf 62 00 00 00 00 00 00 r2 = r6 | |
173 | 6: 85 10 00 00 02 00 00 00 call 2 | |
174 | 0000000000000030: R_BPF_64_32 sec1 | |
175 | 7: 0f 80 00 00 00 00 00 00 r0 += r8 | |
176 | 8: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll | |
177 | 0000000000000040: R_BPF_64_64 global | |
178 | 10: 61 11 00 00 00 00 00 00 r1 = *(u32 *)(r1 + 0) | |
179 | 11: 0f 10 00 00 00 00 00 00 r0 += r1 | |
180 | 12: 95 00 00 00 00 00 00 00 exit | |
181 | ||
182 | Disassembly of section sec1: | |
183 | ||
184 | 0000000000000000 <gfunc>: | |
185 | 0: bf 20 00 00 00 00 00 00 r0 = r2 | |
186 | 1: 2f 10 00 00 00 00 00 00 r0 *= r1 | |
187 | 2: 95 00 00 00 00 00 00 00 exit | |
188 | ||
189 | 0000000000000018 <lfunc>: | |
190 | 3: bf 20 00 00 00 00 00 00 r0 = r2 | |
191 | 4: 0f 10 00 00 00 00 00 00 r0 += r1 | |
192 | 5: 95 00 00 00 00 00 00 00 exit | |
193 | ||
194 | The first relocation corresponds to ``gfunc(a, b)`` where ``gfunc`` has a value of 0, | |
195 | so the ``call`` instruction offset is ``(0 + 0)/8 - 1 = -1``. | |
196 | The second relocation corresponds to ``lfunc(a, b)`` where ``lfunc`` has a section | |
197 | offset ``0x18``, so the ``call`` instruction offset is ``(0 + 0x18)/8 - 1 = 2``. | |
198 | The third relocation corresponds to ld_imm64 of ``global``, which has a section | |
199 | offset ``0``. | |
200 | ||
201 | The following is an example to show how R_BPF_64_ABS64 could be generated:: | |
202 | ||
203 | int global() { return 0; } | |
204 | struct t { void *g; } gbl = { global }; | |
205 | ||
bbaf1ff0 | 206 | Compiled with ``clang --target=bpf -O2 -g -c test.c``, we will see a |
fc8c262e YS |
207 | relocation below in ``.data`` section with command |
208 | ``llvm-readelf -r test.o``:: | |
209 | ||
210 | Relocation section '.rel.data' at offset 0x458 contains 1 entries: | |
211 | Offset Info Type Symbol's Value Symbol's Name | |
212 | 0000000000000000 0000000700000002 R_BPF_64_ABS64 0000000000000000 global | |
213 | ||
214 | The relocation says the first 8-byte of ``.data`` section should be | |
215 | filled with address of ``global`` variable. | |
216 | ||
217 | With ``llvm-readelf`` output, we can see that dwarf sections have a bunch of | |
218 | ``R_BPF_64_ABS32`` and ``R_BPF_64_ABS64`` relocations:: | |
219 | ||
220 | Relocation section '.rel.debug_info' at offset 0x468 contains 13 entries: | |
221 | Offset Info Type Symbol's Value Symbol's Name | |
222 | 0000000000000006 0000000300000003 R_BPF_64_ABS32 0000000000000000 .debug_abbrev | |
223 | 000000000000000c 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str | |
224 | 0000000000000012 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str | |
225 | 0000000000000016 0000000600000003 R_BPF_64_ABS32 0000000000000000 .debug_line | |
226 | 000000000000001a 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str | |
227 | 000000000000001e 0000000200000002 R_BPF_64_ABS64 0000000000000000 .text | |
228 | 000000000000002b 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str | |
229 | 0000000000000037 0000000800000002 R_BPF_64_ABS64 0000000000000000 gbl | |
230 | 0000000000000040 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str | |
231 | ...... | |
232 | ||
233 | The .BTF/.BTF.ext sections has R_BPF_64_NODYLD32 relocations:: | |
234 | ||
235 | Relocation section '.rel.BTF' at offset 0x538 contains 1 entries: | |
236 | Offset Info Type Symbol's Value Symbol's Name | |
237 | 0000000000000084 0000000800000004 R_BPF_64_NODYLD32 0000000000000000 gbl | |
238 | ||
239 | Relocation section '.rel.BTF.ext' at offset 0x548 contains 2 entries: | |
240 | Offset Info Type Symbol's Value Symbol's Name | |
241 | 000000000000002c 0000000200000004 R_BPF_64_NODYLD32 0000000000000000 .text | |
242 | 0000000000000040 0000000200000004 R_BPF_64_NODYLD32 0000000000000000 .text | |
be4033d3 EZ |
243 | |
244 | .. _btf-co-re-relocations: | |
245 | ||
246 | ================= | |
247 | CO-RE Relocations | |
248 | ================= | |
249 | ||
250 | From object file point of view CO-RE mechanism is implemented as a set | |
251 | of CO-RE specific relocation records. These relocation records are not | |
252 | related to ELF relocations and are encoded in .BTF.ext section. | |
3888fa13 | 253 | See :ref:`Documentation/bpf/btf.rst <BTF_Ext_Section>` for more |
be4033d3 EZ |
254 | information on .BTF.ext structure. |
255 | ||
256 | CO-RE relocations are applied to BPF instructions to update immediate | |
257 | or offset fields of the instruction at load time with information | |
258 | relevant for target kernel. | |
259 | ||
260 | Field to patch is selected basing on the instruction class: | |
261 | ||
262 | * For BPF_ALU, BPF_ALU64, BPF_LD `immediate` field is patched; | |
263 | * For BPF_LDX, BPF_STX, BPF_ST `offset` field is patched; | |
264 | * BPF_JMP, BPF_JMP32 instructions **should not** be patched. | |
265 | ||
266 | Relocation kinds | |
267 | ================ | |
268 | ||
269 | There are several kinds of CO-RE relocations that could be split in | |
270 | three groups: | |
271 | ||
272 | * Field-based - patch instruction with field related information, e.g. | |
273 | change offset field of the BPF_LDX instruction to reflect offset | |
274 | of a specific structure field in the target kernel. | |
275 | ||
276 | * Type-based - patch instruction with type related information, e.g. | |
277 | change immediate field of the BPF_ALU move instruction to 0 or 1 to | |
278 | reflect if specific type is present in the target kernel. | |
279 | ||
280 | * Enum-based - patch instruction with enum related information, e.g. | |
281 | change immediate field of the BPF_LD_IMM64 instruction to reflect | |
282 | value of a specific enum literal in the target kernel. | |
283 | ||
284 | The complete list of relocation kinds is represented by the following enum: | |
285 | ||
286 | .. code-block:: c | |
287 | ||
288 | enum bpf_core_relo_kind { | |
289 | BPF_CORE_FIELD_BYTE_OFFSET = 0, /* field byte offset */ | |
290 | BPF_CORE_FIELD_BYTE_SIZE = 1, /* field size in bytes */ | |
291 | BPF_CORE_FIELD_EXISTS = 2, /* field existence in target kernel */ | |
292 | BPF_CORE_FIELD_SIGNED = 3, /* field signedness (0 - unsigned, 1 - signed) */ | |
293 | BPF_CORE_FIELD_LSHIFT_U64 = 4, /* bitfield-specific left bitshift */ | |
294 | BPF_CORE_FIELD_RSHIFT_U64 = 5, /* bitfield-specific right bitshift */ | |
295 | BPF_CORE_TYPE_ID_LOCAL = 6, /* type ID in local BPF object */ | |
296 | BPF_CORE_TYPE_ID_TARGET = 7, /* type ID in target kernel */ | |
297 | BPF_CORE_TYPE_EXISTS = 8, /* type existence in target kernel */ | |
298 | BPF_CORE_TYPE_SIZE = 9, /* type size in bytes */ | |
299 | BPF_CORE_ENUMVAL_EXISTS = 10, /* enum value existence in target kernel */ | |
300 | BPF_CORE_ENUMVAL_VALUE = 11, /* enum value integer value */ | |
301 | BPF_CORE_TYPE_MATCHES = 12, /* type match in target kernel */ | |
302 | }; | |
303 | ||
304 | Notes: | |
305 | ||
306 | * ``BPF_CORE_FIELD_LSHIFT_U64`` and ``BPF_CORE_FIELD_RSHIFT_U64`` are | |
307 | supposed to be used to read bitfield values using the following | |
308 | algorithm: | |
309 | ||
310 | .. code-block:: c | |
311 | ||
312 | // To read bitfield ``f`` from ``struct s`` | |
313 | is_signed = relo(s->f, BPF_CORE_FIELD_SIGNED) | |
314 | off = relo(s->f, BPF_CORE_FIELD_BYTE_OFFSET) | |
315 | sz = relo(s->f, BPF_CORE_FIELD_BYTE_SIZE) | |
316 | l = relo(s->f, BPF_CORE_FIELD_LSHIFT_U64) | |
317 | r = relo(s->f, BPF_CORE_FIELD_RSHIFT_U64) | |
318 | // define ``v`` as signed or unsigned integer of size ``sz`` | |
319 | v = *({s|u}<sz> *)((void *)s + off) | |
320 | v <<= l | |
321 | v >>= r | |
322 | ||
323 | * The ``BPF_CORE_TYPE_MATCHES`` queries matching relation, defined as | |
324 | follows: | |
325 | ||
326 | * for integers: types match if size and signedness match; | |
327 | * for arrays & pointers: target types are recursively matched; | |
328 | * for structs & unions: | |
329 | ||
330 | * local members need to exist in target with the same name; | |
331 | ||
332 | * for each member we recursively check match unless it is already behind a | |
333 | pointer, in which case we only check matching names and compatible kind; | |
334 | ||
335 | * for enums: | |
336 | ||
337 | * local variants have to have a match in target by symbolic name (but not | |
338 | numeric value); | |
339 | ||
340 | * size has to match (but enum may match enum64 and vice versa); | |
341 | ||
342 | * for function pointers: | |
343 | ||
344 | * number and position of arguments in local type has to match target; | |
345 | * for each argument and the return value we recursively check match. | |
346 | ||
347 | CO-RE Relocation Record | |
348 | ======================= | |
349 | ||
350 | Relocation record is encoded as the following structure: | |
351 | ||
352 | .. code-block:: c | |
353 | ||
354 | struct bpf_core_relo { | |
355 | __u32 insn_off; | |
356 | __u32 type_id; | |
357 | __u32 access_str_off; | |
358 | enum bpf_core_relo_kind kind; | |
359 | }; | |
360 | ||
361 | * ``insn_off`` - instruction offset (in bytes) within a code section | |
362 | associated with this relocation; | |
363 | ||
364 | * ``type_id`` - BTF type ID of the "root" (containing) entity of a | |
365 | relocatable type or field; | |
366 | ||
367 | * ``access_str_off`` - offset into corresponding .BTF string section. | |
368 | String interpretation depends on specific relocation kind: | |
369 | ||
370 | * for field-based relocations, string encodes an accessed field using | |
371 | a sequence of field and array indices, separated by colon (:). It's | |
372 | conceptually very close to LLVM's `getelementptr <GEP_>`_ instruction's | |
373 | arguments for identifying offset to a field. For example, consider the | |
374 | following C code: | |
375 | ||
376 | .. code-block:: c | |
377 | ||
378 | struct sample { | |
379 | int a; | |
380 | int b; | |
381 | struct { int c[10]; }; | |
382 | } __attribute__((preserve_access_index)); | |
383 | struct sample *s; | |
384 | ||
385 | * Access to ``s[0].a`` would be encoded as ``0:0``: | |
386 | ||
387 | * ``0``: first element of ``s`` (as if ``s`` is an array); | |
388 | * ``0``: index of field ``a`` in ``struct sample``. | |
389 | ||
390 | * Access to ``s->a`` would be encoded as ``0:0`` as well. | |
391 | * Access to ``s->b`` would be encoded as ``0:1``: | |
392 | ||
393 | * ``0``: first element of ``s``; | |
394 | * ``1``: index of field ``b`` in ``struct sample``. | |
395 | ||
396 | * Access to ``s[1].c[5]`` would be encoded as ``1:2:0:5``: | |
397 | ||
398 | * ``1``: second element of ``s``; | |
399 | * ``2``: index of anonymous structure field in ``struct sample``; | |
400 | * ``0``: index of field ``c`` in anonymous structure; | |
401 | * ``5``: access to array element #5. | |
402 | ||
403 | * for type-based relocations, string is expected to be just "0"; | |
404 | ||
405 | * for enum value-based relocations, string contains an index of enum | |
406 | value within its enum type; | |
407 | ||
408 | * ``kind`` - one of ``enum bpf_core_relo_kind``. | |
409 | ||
410 | .. _GEP: https://llvm.org/docs/LangRef.html#getelementptr-instruction | |
411 | ||
412 | .. _btf_co_re_relocation_examples: | |
413 | ||
414 | CO-RE Relocation Examples | |
415 | ========================= | |
416 | ||
417 | For the following C code: | |
418 | ||
419 | .. code-block:: c | |
420 | ||
421 | struct foo { | |
422 | int a; | |
423 | int b; | |
424 | unsigned c:15; | |
425 | } __attribute__((preserve_access_index)); | |
426 | ||
427 | enum bar { U, V }; | |
428 | ||
429 | With the following BTF definitions: | |
430 | ||
431 | .. code-block:: | |
432 | ||
433 | ... | |
434 | [2] STRUCT 'foo' size=8 vlen=2 | |
435 | 'a' type_id=3 bits_offset=0 | |
436 | 'b' type_id=3 bits_offset=32 | |
437 | 'c' type_id=4 bits_offset=64 bitfield_size=15 | |
438 | [3] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED | |
439 | [4] INT 'unsigned int' size=4 bits_offset=0 nr_bits=32 encoding=(none) | |
440 | ... | |
441 | [16] ENUM 'bar' encoding=UNSIGNED size=4 vlen=2 | |
442 | 'U' val=0 | |
443 | 'V' val=1 | |
444 | ||
445 | Field offset relocations are generated automatically when | |
446 | ``__attribute__((preserve_access_index))`` is used, for example: | |
447 | ||
448 | .. code-block:: c | |
449 | ||
450 | void alpha(struct foo *s, volatile unsigned long *g) { | |
451 | *g = s->a; | |
452 | s->a = 1; | |
453 | } | |
454 | ||
455 | 00 <alpha>: | |
456 | 0: r3 = *(s32 *)(r1 + 0x0) | |
457 | 00: CO-RE <byte_off> [2] struct foo::a (0:0) | |
458 | 1: *(u64 *)(r2 + 0x0) = r3 | |
459 | 2: *(u32 *)(r1 + 0x0) = 0x1 | |
460 | 10: CO-RE <byte_off> [2] struct foo::a (0:0) | |
461 | 3: exit | |
462 | ||
463 | ||
464 | All relocation kinds could be requested via built-in functions. | |
465 | E.g. field-based relocations: | |
466 | ||
467 | .. code-block:: c | |
468 | ||
469 | void bravo(struct foo *s, volatile unsigned long *g) { | |
470 | *g = __builtin_preserve_field_info(s->b, 0 /* field byte offset */); | |
471 | *g = __builtin_preserve_field_info(s->b, 1 /* field byte size */); | |
472 | *g = __builtin_preserve_field_info(s->b, 2 /* field existence */); | |
473 | *g = __builtin_preserve_field_info(s->b, 3 /* field signedness */); | |
474 | *g = __builtin_preserve_field_info(s->c, 4 /* bitfield left shift */); | |
475 | *g = __builtin_preserve_field_info(s->c, 5 /* bitfield right shift */); | |
476 | } | |
477 | ||
478 | 20 <bravo>: | |
479 | 4: r1 = 0x4 | |
480 | 20: CO-RE <byte_off> [2] struct foo::b (0:1) | |
481 | 5: *(u64 *)(r2 + 0x0) = r1 | |
482 | 6: r1 = 0x4 | |
483 | 30: CO-RE <byte_sz> [2] struct foo::b (0:1) | |
484 | 7: *(u64 *)(r2 + 0x0) = r1 | |
485 | 8: r1 = 0x1 | |
486 | 40: CO-RE <field_exists> [2] struct foo::b (0:1) | |
487 | 9: *(u64 *)(r2 + 0x0) = r1 | |
488 | 10: r1 = 0x1 | |
489 | 50: CO-RE <signed> [2] struct foo::b (0:1) | |
490 | 11: *(u64 *)(r2 + 0x0) = r1 | |
491 | 12: r1 = 0x31 | |
492 | 60: CO-RE <lshift_u64> [2] struct foo::c (0:2) | |
493 | 13: *(u64 *)(r2 + 0x0) = r1 | |
494 | 14: r1 = 0x31 | |
495 | 70: CO-RE <rshift_u64> [2] struct foo::c (0:2) | |
496 | 15: *(u64 *)(r2 + 0x0) = r1 | |
497 | 16: exit | |
498 | ||
499 | ||
500 | Type-based relocations: | |
501 | ||
502 | .. code-block:: c | |
503 | ||
504 | void charlie(struct foo *s, volatile unsigned long *g) { | |
505 | *g = __builtin_preserve_type_info(*s, 0 /* type existence */); | |
506 | *g = __builtin_preserve_type_info(*s, 1 /* type size */); | |
507 | *g = __builtin_preserve_type_info(*s, 2 /* type matches */); | |
508 | *g = __builtin_btf_type_id(*s, 0 /* type id in this object file */); | |
509 | *g = __builtin_btf_type_id(*s, 1 /* type id in target kernel */); | |
510 | } | |
511 | ||
512 | 88 <charlie>: | |
513 | 17: r1 = 0x1 | |
514 | 88: CO-RE <type_exists> [2] struct foo | |
515 | 18: *(u64 *)(r2 + 0x0) = r1 | |
516 | 19: r1 = 0xc | |
517 | 98: CO-RE <type_size> [2] struct foo | |
518 | 20: *(u64 *)(r2 + 0x0) = r1 | |
519 | 21: r1 = 0x1 | |
520 | a8: CO-RE <type_matches> [2] struct foo | |
521 | 22: *(u64 *)(r2 + 0x0) = r1 | |
522 | 23: r1 = 0x2 ll | |
523 | b8: CO-RE <local_type_id> [2] struct foo | |
524 | 25: *(u64 *)(r2 + 0x0) = r1 | |
525 | 26: r1 = 0x2 ll | |
526 | d0: CO-RE <target_type_id> [2] struct foo | |
527 | 28: *(u64 *)(r2 + 0x0) = r1 | |
528 | 29: exit | |
529 | ||
530 | Enum-based relocations: | |
531 | ||
532 | .. code-block:: c | |
533 | ||
534 | void delta(struct foo *s, volatile unsigned long *g) { | |
535 | *g = __builtin_preserve_enum_value(*(enum bar *)U, 0 /* enum literal existence */); | |
536 | *g = __builtin_preserve_enum_value(*(enum bar *)V, 1 /* enum literal value */); | |
537 | } | |
538 | ||
539 | f0 <delta>: | |
540 | 30: r1 = 0x1 ll | |
541 | f0: CO-RE <enumval_exists> [16] enum bar::U = 0 | |
542 | 32: *(u64 *)(r2 + 0x0) = r1 | |
543 | 33: r1 = 0x1 ll | |
544 | 108: CO-RE <enumval_value> [16] enum bar::V = 1 | |
545 | 35: *(u64 *)(r2 + 0x0) = r1 | |
546 | 36: exit |