[Bug target/107181] new test case gcc.dg/pr25521.c fails in r13-2952-ga0aafbc324aa90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107181 Cupertino Miranda changed: What|Removed |Added CC||cupertino.miranda at oracle dot co ||m --- Comment #4 from Cupertino Miranda --- Just would like to mention that I have been working on this and will soon submit some patches for review.
[Bug target/114431] bpf: GCC generates unverifiable code for systemd restrict_fs_bpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431 Cupertino Miranda changed: What|Removed |Added CC||cupertino.miranda at oracle dot co ||m --- Comment #6 from Cupertino Miranda --- Based on the comparisson of clang and gcc output over the provided preprocessed files, I believe that the patch pushed resolves the problem. Have written to the original systemd github issue to mention the fix and request for further verification.
[Bug target/114523] New: bpf: ssa-phiopt optimization generates unverifiable code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114523
Bug ID: 114523
Summary: bpf: ssa-phiopt optimization generates unverifiable
code.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: cupertino.miranda at oracle dot com
Target Milestone: ---
BTF verifier is a static analyzer that identifies possible kernel threats with
BPF applications.
The example below is a small reproducer obtained from debugging the last issue
presented in https://github.com/systemd/systemd/issues/31888.
extern int bar ();
int baz;
int foo ()
{
int quux = bar ();
if (baz)
{
if (quux)
return 1;
}
else
{
if (!quux)
return 1;
}
return 0;
}
The following code gets optimized by phiopt2 like:
Removing basic block 6
Removing basic block 4
Removing basic block 3
Removing basic block 5
Merging blocks 2 and 7
int foo ()
{
int quux;
int baz.0_1;
int _2;
_Bool _6;
_Bool _11;
_Bool _12;
[local count: 1073741824]:
quux_5 = bar ();
baz.0_1 = baz;
_6 = quux_5 == 0;
_11 = baz.0_1 != 0;
_12 = _6 ^ _11;
_2 = (int) _12;
return _2;
}
The produced code from this optimization, in the original issue in github,
results in unverifiable code for the BPF execution environment.
For now it is unclear if the problem is within the verifier or not.
As a resolution for the problem 2 paths should be taken:
- Create a reproducer in the testing environment for bpf-next and report the
problem within the respective mailing list.
- Disable the optimization for BPF until the verifier fixes the limitation if
possible.
[Bug target/110770] New: bpf: add pseudoc assembly dialect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110770 Bug ID: 110770 Summary: bpf: add pseudoc assembly dialect Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: cupertino.miranda at oracle dot com Target Milestone: --- LLVM supports a different assembly dialect. We should support the same assembly format in GCC. A reference for these instructions can be found in: https://gcc.gnu.org/wiki/BPFBackEnd
[Bug target/113225] New: bpf: attributekernel_helper function declarations create a BTF_FUNC_EXTERN.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113225
Bug ID: 113225
Summary: bpf: attributekernel_helper function declarations
create a BTF_FUNC_EXTERN.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: cupertino.miranda at oracle dot com
Target Milestone: ---
When using attribute kernel_helper such as the one in the example:
extern int foo (int arg) __attribute__((kernel_helper (666)));
int bar ()
{
return foo (20);
}
The following BTF entries are created:
[1] int 'int'(1U#B) size=4U#B offset=0UB#b bits=32UB#b SIGNED
[2] func_proto type=1
param '' type=1
[3] func_proto type=1
[4] func 'foo'(5U#B) type=2 linkage=0 (extern)
[5] func 'bar'(9U#B) type=3 linkage=1 (global)
BTF information is generated for the extern function declaration, imposing some
problem to tools such as bpftool that relies on BTF information to validate
completeness of the BTF information.
Since kernel helpers are not true functions the BTF information created,
although accurate with how the function is declared, it is not accurate with
its semantics.
Plan resolution is to skip btf output to any attributed kernel_helper function
declaration, since the BTF information in this case is not really required.
[Bug target/113453] New: bpf: func_info and line_info missing in .BTF.ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113453
Bug ID: 113453
Summary: bpf: func_info and line_info missing in .BTF.ext
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: cupertino.miranda at oracle dot com
Target Milestone: ---
This is a placeholder for the implementation for func_info and line_info
content in .BTF.ext section, required in particular cases by the kernel
verifier.
For the particular case of func_info, it is a required when get identified as a
BPF_PSEUDO_FUNC.
# if (insn->src_reg == BPF_PSEUDO_FUNC) {
# ...
# if (!aux->func_info) {
# verbose(env, "missing btf func_info\n");
# return -EINVAL;
# }
Which gets triggered by the following code:
# /* mark the insn, so it's recognized by insn_is_pseudo_func() */
# if (relo->type == RELO_SUBPROG_ADDR)
# insn[0].src_reg = BPF_PSEUDO_FUNC;
Documentation for the content of .BTF.ext can be found in:
- https://docs.kernel.org/bpf/btf.html
func_info keeps a record of all entry point addresses and section to any
BTF_KIND_FUNC entry. By traversing the func_info content the BPF infrastructure
can recover code location for any BTF_KIND_FUNC.
A few requirements to note for the implementation are, as mentioned in
documentation:
for func_info:
- func_info[0].insn_off must be 0.
- the func_info insn_off is in strictly increasing order and matches bpf func
boundaries.
for line_info:
- the first insn in each func must have a line_info record pointing to it.
- the line_info insn_off is in strictly increasing order.
Other observations are that function entry symbol relocation in the func_info
require that all relocations in func_info should be resolved within the object
file (resolved by gas), relative to the function section symbol.
This was observed in the content of the clang objects.
The assembly of one of this entries in clang .s file is:
.long 7
.long .Lfunc_begin2
Within the object one can see:
38: 07 00 00 00 30 00 00 00 add %r0,48
3c: R_BPF_64_NODYLD32 tc
.Lfunc_begin2 is removed from the object, but its value is in-place resolved
with the value 0x30 (offset of .Lfunc_begin2 from tc) as the addend from its
section "tc", in this particular case.
[Bug target/117068] bpf: add support for preserve_static_offset attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117068 --- Comment #3 from Cupertino Miranda --- Indeed middle-end is already doing that conversion for BPF, in particular because of CO-RE implementation, which at gimple, turns A->B into A + __builtin_CORE_offset(B>), being B> internal meta information for the original access. When you have 2 consecutive conditional uses of A: OUT = COND ? A + __builtin_CORE_offset(B>) : A + __builtin_CORE_offset(C>); then the middle end is already doing the CSE, and converting it in: OUT = A + (COND ? __builtin_CORE_offset(B>) : __builtin_CORE_offset(C>)); This all to say that, we need to figure out how to limit CSE from optimizing variables that are attributed as well, through the middle-end. Is there any middle-end construct that would allow us to disable CSE for such variables/parameters? Except encapsulating it in a builtin, which I would hate to do. Regarding back-end, could we possibly at expand check for the attribute and expand to an unspec that would be classified by the target as a legitimate address. The address would be opaque through all the backend. I wonder if this would be Ok for RA or any other RTL passes?
[Bug target/117068] New: bpf: add support for preserve_static_offset attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117068 Bug ID: 117068 Summary: bpf: add support for preserve_static_offset attribute Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: cupertino.miranda at oracle dot com Target Milestone: --- BPF verifier imposes special code limitations when accessing specific variables/arguments. One example is for the access to "context pointers" struct fields (provided in R1 at application start). Any load or store to a context pointer must always be in the form of "register+offset" to which the register would contain the address to the base of the structure and the full offset for the field being accessed. Any early offset computation to a context pointer register/value does (for the verifier) declassify the register from being a context pointer and denies any loads or stores from using the mutated register. An actual example of such denying is this selftest run fail: reg type unsupported for arg#0 function get_vma_offset#8723 0: R1=ctx() R10=fp0 0: (18) r0 = 0x10 ; R0_w=16 2: (bf) r2 = r1 ; R1=ctx() R2_w=ctx() 3: (0f) r2 += r0 ; R0_w=16 R2_w=ctx(off=16) 4: (79) r0 = *(u64 *)(r1 +8);R0_w=ptr_or_null_task_struct(id=1) R1=ctx(); 5: (15) if r0 == 0x0 goto pc+21 ; R0_w=ptr_task_struct() 6: (79) r2 = *(u64 *)(r2 +0) dereference of modified ctx ptr R2 off=16 disallowed BPF verifier documentation describing the limitations: https://docs.kernel.org/bpf/verifier.html Compilers do not by default have the constructs to impose these target limitations. LLVM solution for this problem is to define the struct attribute preserve_static_offset that will enforce that any reference to the particular struct would respect the BPF verifier requirements. LLVM proposal at: https://reviews.llvm.org/D133361
