Skip to content

K
Kernel

openeuler / Kernel
大约 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 06 10月, 2022 1 次提交
  3. 21 9月, 2022 1 次提交
  5. 21 7月, 2022 1 次提交
  7. 29 6月, 2022 1 次提交
  9. 08 6月, 2022 1 次提交
  11. 01 3月, 2022 1 次提交
  13. 09 2月, 2022 2 次提交
  15. 14 12月, 2021 1 次提交
  17. 30 11月, 2021 1 次提交
  19. 12 11月, 2021 2 次提交
  21. 26 10月, 2021 1 次提交
  23. 23 10月, 2021 2 次提交
  25. 22 10月, 2021 1 次提交
  27. 21 10月, 2021 2 次提交
  29. 19 10月, 2021 1 次提交
  31. 15 9月, 2021 1 次提交
  33. 21 7月, 2021 2 次提交
  35. 17 7月, 2021 4 次提交
  37. 26 5月, 2021 1 次提交
  39. 20 3月, 2021 1 次提交
    • J
      libbpf: Fix BTF dump of pointer-to-array-of-struct · 901ee1d7
      由 Jean-Philippe Brucker 提交于 
      The vmlinux.h generated from BTF is invalid when building
drivers/phy/ti/phy-gmii-sel.c with clang:

vmlinux.h:61702:27: error: array type has incomplete element type ‘struct reg_field’
61702 |  const struct reg_field (*regfields)[3];
      |                           ^~~~~~~~~

bpftool generates a forward declaration for this struct regfield, which
compilers aren't happy about. Here's a simplified reproducer:

	struct inner {
		int val;
	};
	struct outer {
		struct inner (*ptr_to_array)[2];
	} A;

After build with clang -> bpftool btf dump c -> clang/gcc:
./def-clang.h:11:23: error: array has incomplete element type 'struct inner'
        struct inner (*ptr_to_array)[2];

Member ptr_to_array of struct outer is a pointer to an array of struct
inner. In the DWARF generated by clang, struct outer appears before
struct inner, so when converting BTF of struct outer into C, bpftool
issues a forward declaration to struct inner. With GCC the DWARF info is
reversed so struct inner gets fully defined.

That forward declaration is not sufficient when compilers handle an
array of the struct, even when it's only used through a pointer. Note
that we can trigger the same issue with an intermediate typedef:

	struct inner {
	        int val;
	};
	typedef struct inner inner2_t[2];
	struct outer {
	        inner2_t *ptr_to_array;
	} A;

Becomes:

	struct inner;
	typedef struct inner inner2_t[2];

And causes:

./def-clang.h:10:30: error: array has incomplete element type 'struct inner'
	typedef struct inner inner2_t[2];

To fix this, clear through_ptr whenever we encounter an intermediate
array, to make the inner struct part of a strong link and force full
declaration.

Fixes: 351131b5 ("libbpf: add btf_dump API for BTF-to-C conversion")
Signed-off-by: NJean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: NAndrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20210319112554.794552-2-jean-philippe@linaro.org
      901ee1d7
  41. 19 3月, 2021 1 次提交
  43. 05 3月, 2021 1 次提交
  45. 01 10月, 2020 1 次提交
  47. 29 9月, 2020 1 次提交
  49. 19 8月, 2020 3 次提交
  51. 14 8月, 2020 1 次提交
    • A
      libbpf: Handle BTF pointer sizes more carefully · 44ad23df
      由 Andrii Nakryiko 提交于 
      With libbpf and BTF it is pretty common to have libbpf built for one
architecture, while BTF information was generated for a different architecture
(typically, but not always, BPF). In such case, the size of a pointer might
differ betweem architectures. libbpf previously was always making an
assumption that pointer size for BTF is the same as native architecture
pointer size, but that breaks for cases where libbpf is built as 32-bit
library, while BTF is for 64-bit architecture.

To solve this, add heuristic to determine pointer size by searching for `long`
or `unsigned long` integer type and using its size as a pointer size. Also,
allow to override the pointer size with a new API btf__set_pointer_size(), for
cases where application knows which pointer size should be used. User
application can check what libbpf "guessed" by looking at the result of
btf__pointer_size(). If it's not 0, then libbpf successfully determined a
pointer size, otherwise native arch pointer size will be used.

For cases where BTF is parsed from ELF file, use ELF's class (32-bit or
64-bit) to determine pointer size.

Fixes: 8a138aed ("bpf: btf: Add BTF support to libbpf")
Fixes: 351131b5 ("libbpf: add btf_dump API for BTF-to-C conversion")
Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200813204945.1020225-5-andriin@fb.com
      44ad23df
  53. 13 8月, 2020 1 次提交
  55. 31 7月, 2020 1 次提交
  57. 14 7月, 2020 1 次提交
    • A
      libbpf: Support stripping modifiers for btf_dump · 7c819e70
      由 Andrii Nakryiko 提交于 
      One important use case when emitting const/volatile/restrict is undesirable is
BPF skeleton generation of DATASEC layout. These are further memory-mapped and
can be written/read from user-space directly.

For important case of .rodata variables, bpftool strips away first-level
modifiers, to make their use on user-space side simple and not requiring extra
type casts to override compiler complaining about writing to const variables.

This logic works mostly fine, but breaks in some more complicated cases. E.g.:

    const volatile int params[10];

Because in BTF it's a chain of ARRAY -> CONST -> VOLATILE -> INT, bpftool
stops at ARRAY and doesn't strip CONST and VOLATILE. In skeleton this variable
will be emitted as is. So when used from user-space, compiler will complain
about writing to const array. This is problematic, as also mentioned in [0].

To solve this for arrays and other non-trivial cases (e.g., inner
const/volatile fields inside the struct), teach btf_dump to strip away any
modifier, when requested. This is done as an extra option on
btf_dump__emit_type_decl() API.
Reported-by: NAnton Protopopov <a.s.protopopov@gmail.com>
Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200713232409.3062144-2-andriin@fb.com
      7c819e70
  59. 10 6月, 2020 1 次提交