On 5/3/24 2:02 PM, Indu Bhagat wrote:
> On 5/2/24 10:11, David Faust wrote:
>> This commit makes some structural changes to the CTF/BTF debug info
>> emission. In particular:
>>
>> a) CTF is new always fully generated and emitted before any
>> BTF-relate
This patch enables -fprune-btf by default in the BPF backend when
generating BTF information, and fixes BPF CO-RE generation when using
-fprune-btf.
When generating BPF CO-RE information, we must ensure that types used
in CO-RE relocations always have sufficient BTF information emited so
that the
This patch heavily refactors btfout.cc to take advantage of the
structural changes in the prior commits.
Now that inter-type references are internally stored as simply pointers,
all the painful, brittle, confusing infrastructure that was used in the
process of converting CTF type IDs to BTF type
This patch adds a new option, -fprune-btf, to control BTF debug info
generation.
As the name implies, this option enables a kind of "pruning" of the BTF
information before it is emitted. When enabled, rather than emitting
all type information translated from DWARF, only information for types
Previously it was not supported to generate both CTF and BTF debug info
in the same compiler run, as both formats made incompatible changes to
the same internal data structures.
With the structural change in the prior patch, in particular the
guarantee that CTF will always be fully emitted before
This patch replaces all inter-type references in the ctfc internal data
structures with pointers, rather than the references-by-ID which were
used previously.
A couple of small updates in the BPF backend are included to make it
compatible with the change.
This change is only to the in-memory
makes BTF pruning work with BPF CO-RE, and enables the pruning
by default in the BPF backend.
Tested on x86_64-linux-gnu, and on x86_64-linux-gnu host for
bpf-unknown-none target.
Also heavily tested with Linux kernel BPF selftests.
No known regressions.
David Faust (6):
ctf, btf: restructu
This commit makes some structural changes to the CTF/BTF debug info
emission. In particular:
a) CTF is new always fully generated and emitted before any
BTF-related procedures are run. This means that BTF-related
functions can change, even irreversibly, the shared in-memory
On 5/1/24 12:15, David Faust wrote:
> This patch replaces all inter-type references in the ctfc internal data
> structures with pointers, rather than the references-by-ID which were
> used previously.
>
> A couple of small updates in the BPF backend are included to make
This patch heavily refactors btfout.cc to take advantage of the
structural changes in the prior commits.
Now that inter-type references are internally stored as simply pointers,
all the painful, brittle, confusing infrastructure that was used in the
process of converting CTF type IDs to BTF type
This patch replaces all inter-type references in the ctfc internal data
structures with pointers, rather than the references-by-ID which were
used previously.
A couple of small updates in the BPF backend are included to make it
compatible with the change.
This change is only to the in-memory
This patch adds a new option, -fprune-btf, to control BTF debug info
generation.
As the name implies, this option enables a kind of "pruning" of the BTF
information before it is emitted. When enabled, rather than emitting
all type information translated from DWARF, only information for types
This patch enables -fprune-btf by default in the BPF backend when
generating BTF information, and fixes BPF CO-RE generation when using
-fprune-btf.
When generating BPF CO-RE information, we must ensure that types used
in CO-RE relocations always have sufficient BTF information emited so
that the
This commit makes some structural changes to the CTF/BTF debug info
emission. In particular:
a) CTF is new always fully generated and emitted before any
BTF-related procedures are run. This means that BTF-related
functions can change, even irreversibly, the shared in-memory
nformation by a factor of 10.
Patch 6 makes BTF pruning work with BPF CO-RE, and enables the pruning
by default in the BPF backend.
Tested on x86_64-linux-gnu, and on x86_64-linux-gnu host for
bpf-unknown-none target.
Also heavily tested with Linux kernel BPF selftests.
No known regressions.
Davi
Previously it was not supported to generate both CTF and BTF debug info
in the same compiler run, as both formats made incompatible changes to
the same internal data structures.
With the structural change in the prior patch, in particular the
guarantee that CTF will always be fully emitted before
BTF is the standard debug info used with BPF programs, so it makes sense
to default to BTF rather than DWARF.
Tested on x86_64-linux-gnu host for bpf-unknown-none target.
gcc/
* config/bpf/bpf.h (PREFERRED_DEBUGGING_TYPE): Set to BTF_DEBUG.
gcc/testsuite/
*
Compiling a BPF program with CO-RE relocations (and BTF) while also
passing -gtoggle led to an inconsistent state where CO-RE support was
enabled but BTF would not be generated, and this was not caught by the
existing option parsing. This led to an ICE when generating the CO-RE
relocation info,
Hi Cupertino,
On 4/18/24 13:58, Cupertino Miranda wrote:
> Hi David, everyone,
>
> Following Davids last review I decided to properly detect error cases,
> as suggested.
> The error however should be reported earlier in compilation in
> pack_enum_valud function, where all the errors are
On 4/17/24 11:44, Cupertino Miranda wrote:
> The BPF backend was allocating an unnecessarily large string when
> constructing CO-RE relocations for enum types.
>
> gcc/ChangeLog:
> * config/bpf/core-builtins.cc (process_enum_value): Correct
> string allocation.
> ---
>
This patch fixes a small error that could occur in the debug comment
when emitting a type reference with btf_asm_type_ref.
While working on a previous patch, I noticed the following in the asm
output for the test btf-bitfields-4.c:
...
.long 0x39# MEMBER 'c' idx=3
[Changes from v1: use btf_dmd_representable_bitfield_p in
btf_asm_sou_member, instead of a slightly incorrect equivalent check.]
This patch fixes an issue with mangled BTF that could occur when
a struct type contains a bitfield member which cannot be represented
in BTF. It is undefined what
On 4/11/24 13:40, Indu Bhagat wrote:
> On 4/11/24 11:53, David Faust wrote:
>> This patch fixes an issue with mangled BTF that could occur when
>> a struct type contains a bitfield member which cannot be represented
>> in BTF. It is undefined what should happen in s
This patch fixes an issue with mangled BTF that could occur when
a struct type contains a bitfield member which cannot be represented
in BTF. It is undefined what should happen in such cases, but we can
at least do something reasonable.
Commit
936dd627cd9 "btf: do not skip members of data
Hi Cupertino,
On 4/11/24 04:11, Cupertino Miranda wrote:
> Code was allocating way too much space for the string.
A little bit more description would not hurt. Perhaps you could say
something like:
"The BPF backend was allocating an unnecessarily large string when
constructing CO-RE relocations
Hi Indu,
On 4/10/24 11:25, Indu Bhagat wrote:
> Testing the previous fix in gen_ctf_sou_type () reveals an issue in BTF
> generation, however: BTF emission was currently decrementing the vlen
> (indicating the number of members) to skip members of type CTF_K_UNKNOWN
> altogether, but still
On 4/10/24 11:25, Indu Bhagat wrote:
> PR debug/112878: ICE: in ctf_add_slice, at ctfc.cc:499 with _BitInt > 255 in
> a struct and -gctf1
>
> The CTF generation in GCC does not have a mechanism to roll-back an
> already added type. In this testcase presented in the PR, we hit a
> representation
This test failed on powerpc --target_board=unix'{-m32}' because two
variables were not placed in sections where the test silently (and
incorrectly) assumed they would be.
The important thing for the test is only that BTF_KIND_DATASEC entries
are NOT generated for the extern variable declarations
The behavior introduced in
fa60ac54964 btf: Emit labels in DATASEC bts_offset entries.
is only fully correct when compiling for the BPF target with BPF CO-RE
enabled. In other cases, depending on optimizations, it can result in
an incorrect symbol reference in the entry bts_offset field for a
Hi Jakub,
On 3/27/24 04:16, Jakub Jelinek wrote:
> On Wed, Mar 27, 2024 at 11:18:49AM +0100, Jakub Jelinek wrote:
>>> -/* The offset entry for each variable in a DATSEC should be 0 at compile
>>> time. */
>>> -/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset" 7 } } */
>>> +/*
On 3/26/24 07:28, Cupertino Miranda wrote:
> Hi everyone,
>
> This patch is an expected fix for the issue reported by systemd in:
> https://github.com/systemd/systemd/issues/31888
> Also, Jose Marchesi opened the following bugzilla to report it:
>
On 3/13/24 07:24, Cupertino Miranda wrote:
> Any unnamed structure field if not a member of the BTF_KIND_STRUCT.
typo: if -> is
I'd suggest to clarify that "any unnamed structure field" is really
any unnamed non-struct-or-union field, since anonymous inner structs
and unions certainly are
On 3/13/24 07:24, Cupertino Miranda wrote:
> Although part of all CO-RE relocation data, type based relocations do
> not require an access string.
> Initial implementation defined it as an empty string.
> On the other hand, libbpf when parsing the CO-RE relocations verifies
> that those strings
On 3/14/24 10:16, Jose E. Marchesi wrote:
>
> Hi David.
>
>> Change the BPF backend to define INT8_TYPE with an explicit sign, rather
>> than a plain char. This is in line with other targets and removes the
>> risk of int8_t being affected by the signedness of the plain char type
>> of the
Change the BPF backend to define INT8_TYPE with an explicit sign, rather
than a plain char. This is in line with other targets and removes the
risk of int8_t being affected by the signedness of the plain char type
of the host system.
Tested on x86_64-linux-gnu host for bpf-unknown-none.
Sanity
[Changes from v1:
- Error if threshold is exceeded instead of silently emitting libcall
- Update test accordingly
- Expand documentation to explain this behavior ]
BPF cannot fall back on library calls to implement memmove, memcpy and
memset, so we attempt to expand these inline always if
The test was trying to do too much by both checking for an error, and
checking the resulting assembly. Of course, due to the error no asm was
produced, so the scan-asm went unresolved. Split it into two separate
tests to fix the issue.
Tested on x86_64-linux-gnu host for bpf-unknown-none target.
BPF cannot fall back on library calls to implement memmove, memcpy and
memset, so we attempt to expand these inline always if possible.
However, this inline expansion was being attempted even for excessively
large operations, which could result in gcc consuming huge amounts of
memory and hanging.
On 3/5/24 00:47, Indu Bhagat wrote:
> From: Cupertino Miranda
>
> [Changes from V2]
> - Fixed aarch64 new FAILs reported by Linaro CI.
> - Fixed typos and other nits pointed out in V2.
> [End of changes from V2]
OK, thanks.
>
> PR debug/114186
>
> DWARF DIEs of type
Hi Indu, Cupertino,
On 3/4/24 10:00, Indu Bhagat wrote:
> From: Cupertino Miranda
>
> [Changes from V1]
> - Refactor the code a bit.
> [End of changes from V1]
>
> PR debug/114186
>
> DWARF DIEs of type DW_TAG_subrange_type are linked together to represent
> the information about the
Similar to memmove and memcpy, the BPF backend cannot fall back on a
library call to implement __builtin_memset, and should always expand
calls to it inline if possible.
This patch implements simple inline expansion of memset in the BPF
backend in a verifier-friendly way. Similar to memcpy and
The array member of struct SFOO in the ctf-file-scope-1 caused the test
to fail for the BPF target, since BPF does not support dynamic stack
allocation. The array does not need to variable length for the sake of
the test, so make it fixed length instead to allow the test to run
successfully for
Hi Cupertino,
On 2/27/24 11:04, Cupertino Miranda wrote:
> Kernel verifier complains in some particular cases for missing func_info
> implementation in .BTF.ext. This patch implements it.
>
> Strings are cached locally in coreout.cc to avoid adding duplicated
> strings in the string list. This
On 2/27/24 11:04, Cupertino Miranda wrote:
> gcc/ChangeLog:
>
> * config.gcc (target_gtfiles): Changes coreout to btfext-out.
> (extra_objs): Changes coreout to btfext-out.
> * config/bpf/coreout.cc: Renamed to btfext-out.cc.
> * config/bpf/btfext-out.cc: Added.
> *
On 2/27/24 11:04, Cupertino Miranda wrote:
> BPF applications, when generating BTF information should always create a
> .BTF.ext section.
> Current implementation was only creating it when -mco-re option was used.
> This patch makes .BTF.ext always be generated for BPF target objects.
> The
Hi Cupertino,
Similar to patch 1, please use present tense to match the style of
existing commits, in commit message and in ChangeLog.
On 2/27/24 11:04, Cupertino Miranda wrote:
> Added a traversal function to traverse all BTF_KIND_FUNC nodes with a
> callback function. Used for .BTF.ext section
Hi Cupertino,
Just some nits below. Apologies for incoming pedantry.
On 2/27/24 11:04, Cupertino Miranda wrote:
> This patch correct the aditition of +1 on the type id, which originally
> was done in the wrong location and leaded to func_sts->dtd_type for
> BTF_KIND_FUNCS struct data to contain
On 2/20/24 02:24, Cupertino Miranda wrote:
> gcc/ChangeLog:
> * config.gcc (target_gtfiles): changed coreout to btfext-out.
> (extra_objs): changed coreout to btfext-out.
I think these entries should start with a capital letter ("Changed...").
> * config/bpf/coreout.cc:
On 2/20/24 02:24, Cupertino Miranda wrote:
> Added a traversal function to traverse all BTF_KIND_FUNC nodes with a
> callback function. Used for .BTF.ext section content creation.
>
> gcc/ChangeLog
>
> * btfout.cc (output_btf_func_types): use FOR_EACH_VEC_ELT.
>
[Changes from v2:
- Fix incorrectly passing a location instead of OPT_W* for warning ().
- Reword warning/error message and test accordingly. ]
[Changes from v1: Jose's review comments, all of which I agree with.
- Fix 'implments' typo in commit message.
- Change check that alignment is
On 2/20/24 12:37, Jose E. Marchesi wrote:
>
> Hi Faust.
>
>> +bool
>> +bpf_expand_cpymem (rtx *operands, bool is_move)
>> +{
>> + /* Size must be constant for this expansion to work. */
>> + if (!CONST_INT_P (operands[2]))
>> +{
>> + const char *name = is_move ? "memmove" :
Hi Cupertino,
On 2/20/24 02:24, Cupertino Miranda wrote:
> Dissociated .BTF.ext from the CO-RE relocations creation. Improvement of
> allocation/deallocation of BTF structures. Moving deallocation to final
> when needed.
>
> gcc/ChangeLog:
>
> * config/bpf/bpf.cc (bpf_option_override):
On 2/20/24 02:24, Cupertino Miranda wrote:
> This patch correct the aditition of +1 on the type id, which originally
> was done in the wrong location and leaded to func_sts->dtd_type for
> BTF_KIND_FUNCS struct data to contain the type id of the previous entry.
>
> gcc/ChangeLog:
> *
[Changes from v1: Jose's review comments, all of which I agree with.
- Fix 'implments' typo in commit message.
- Change check that alignment is CONST_INT to gcc_assert ().
- Change default case in alignment switch to gcc_unreachable ().
- Reword error message for non-constant size
BPF programs are not typically linked, which means we cannot fall back
on library calls to implement __builtin_{memmove,memcpy} and should
always expand them inline if possible.
GCC already successfully expands these builtins inline in many cases,
but failed to do so for a few for simple cases
Commit 77d0f9ec3809b4d2e32c36069b6b9239d301c030 inadvertently changed
the normal asm dialect instruction template for zero_extendqidi2 from
ldxb to ldxh. Fix that.
Tested for bpf-unknown-none on x86_64-linux-gnu host.
gcc/
* config/bpf/bpf.md (zero_extendqidi2): Correct asm template to
Hi Cupetino,
On 1/8/24 03:05, Cupertino Miranda wrote:
> Hi everyone,
>
> This patch address the problem reported in:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113225
>
> Looking forward to your review.
LGTM, thanks. Please apply.
>
> Cheers,
> Cupertino
>
>
> This patch fix a problem
Hi Cupertino,
On 1/8/24 02:55, Cupertino Miranda wrote:
> Hi everyone,
>
> This patch adds a comment to the BTF strings regarding their position
> within the section. This is useful for assembly inspection purposes.
>
> Regards,
> Cupertino
>
> When using -dA, this function was only printing
The BTF specification does not formally define a representation for
forward-declared enum types such as:
enum Foo;
Forward-declarations for struct and union types are represented by
BTF_KIND_FWD, which has a 1-bit flag distinguishing the two.
The de-facto standard format used by other tools
On 12/5/23 13:28, Indu Bhagat wrote:
> On 12/4/23 15:47, David Faust wrote:
>> The process of creating BTF_KIND_DATASEC records involves iterating
>> through variable declarations, determining which section they will be
>> placed in, and creating an entry in the appro
The process of creating BTF_KIND_DATASEC records involves iterating
through variable declarations, determining which section they will be
placed in, and creating an entry in the appropriate DATASEC record
accordingly.
For variables without e.g. an explicit __attribute__((section)), we use
On 11/30/23 14:17, Indu Bhagat wrote:
> PR debug/112768 - btf: fix asm comment output for BTF_KIND_FUNC* kinds
>
> The patch adds a small function to abstract out the detail and return
> the name of the type. The patch also fixes the issue of BTF_KIND_FUNC
> appearing in the comments with a
Hi Indu,
On 11/30/23 14:18, Indu Bhagat wrote:
> PR debug/112656 - btf: function prototypes generated with name
>
> With this patch, all BTF_KIND_FUNC_PROTO will appear anonymous in the
> generated BTF section.
>
> As noted in the discussion in the bugzilla, the number of
> BTF_KIND_FUNC_PROTO
The BPF "pseudo-C" assembly dialect uses semi-colon (;) to separate
statements, not to begin line comments. The GNU assembler was recently
changed accordingly:
https://sourceware.org/pipermail/binutils/2023-November/130867.html
This patch adapts the BPF backend in GCC accordingly, to use a
Hi Cupertino,
On 11/27/23 09:21, Cupertino Miranda wrote:
> Hi everyone,
>
> David: Thanks for the v1 review.
>
> This version adds the following;
> - test case,
> - improves condition logic,
> - fixes mask typo.
>
> Looking forward to your review.
v2 LGTM, please apply.
Thanks!
>
> v1
On 11/13/23 14:35, Cupertino Miranda wrote:
> The parser plugin handler that is responsible for collecting enum values
> information was being removed way too early.
> bpf_resolve_overloaded_core_builtin is called by the parser.
> It was moved to the function execute_lower_bpf_core.
>
OK,
Hi Cupertino,
A couple of comments inline.
On 11/13/23 14:37, Cupertino Miranda wrote:
> This patch fixes a BTF, which would become invalid when having
> smaller then 4 byte definitions of enums.
> For example, when using the __attribute__((mode(byte))) in the enum
> definition.
Please add a
On 11/13/23 14:36, Cupertino Miranda wrote:
> gcc/ChangeLog:
> * config/bpf/core-builtins.cc (core_mark_as_access_index):
> Corrected check.
OK, thanks.
> ---
> gcc/config/bpf/core-builtins.cc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On 10/31/23 09:58, David Faust wrote:
> Hi Cupertino,
>
> On 10/30/23 12:39, Cupertino Miranda wrote:
>>
>> Hi everyone,
>>
>> Please find a new version for the review as inline attachment.
>>
>> Best regards,
>> Cupertino
>>
Hi Cupertino,
On 10/30/23 12:39, Cupertino Miranda wrote:
>
> Hi everyone,
>
> Please find a new version for the review as inline attachment.
>
> Best regards,
> Cupertino
>
This version LGTM.
Thanks!
>
> Changes from v4:
> - Implemented TARGET_DELEGITIMIZE_ADDRESS target hook as the
On 10/26/23 08:08, Cupertino Miranda wrote:
>
> Changes from v1:
> - Fixed Davids remarks on initial patch.
> - Fixed mistake with deleted '*'.
>
> Changes from v2:
> - Reversed return value for bpf_const_not_ok_for_debug_p function.
Hmm..
> +static bool
> +bpf_const_not_ok_for_debug_p
On 10/25/23 11:51, Cupertino Miranda wrote:
> Hi everyone,
>
> This patch contains some more recent improvements to BPF CO-RE builtins.
> Please find further details of the changes on the patch header.
>
> Looking forward for your review and comments.
>
> Best regards,
> Cupertino Miranda
Hi
, David Faust via Gcc-patches wrote:
> Hello,
>
> This series adds support for a new attribute, "btf_decl_tag" in GCC.
> The same attribute is already supported in clang, and is used by various
> components of the BPF ecosystem.
>
> The purpose of the attribute is
The BPF virtual machine does not support neg nor neg32 instructions with
an immediate.
The erroneous instructions were removed from binutils:
https://sourceware.org/pipermail/binutils/2023-August/129135.html
Change the define_insn so that an immediate cannot be accepted.
>From testing, a
This define_insn is never used, since a sign-extend to the same mode is
just a move, so delete it.
Tested on x86_64-linux-gnu host for bpf-unknown-none target.
gcc/
* config/bpf/bpf.md (extendsisi2): Delete useless define_insn.
---
gcc/config/bpf/bpf.md | 7 ---
1 file changed, 7
In the BPF pseudo-c assembly dialect, registers treated as 32-bits
rather than the full 64 in various instructions ought to be printed as
"wN" rather than "rN". But bpf_print_register () was only doing this
for specifically SImode registers, meaning smaller modes were printed
incorrectly.
This
Ping for this series.
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624156.html
Thanks
On 7/11/23 14:57, David Faust via Gcc-patches wrote:
> Hello,
>
> This series adds support for a new attribute, "btf_decl_tag" in GCC.
> The same attribute is already supported
Claudiu Zissulescu
callgraph Martin Jambor
C front endMarek Polacek
CTF, BTF Indu Bhagat
-CTF, BTF David Faust
+CTF, BTF, bpf port David Faust
dataflow
On 7/27/23 15:27, Jose E. Marchesi wrote:
>
> Hi David.
> Thanks for the patch.
>
>> BPF ISA V4 introduces sign-extending move and load operations. This
>> patch makes the BPF backend generate those instructions, when enabled
>> and useful.
>>
>> A new option, -m[no-]smov gates generation of
BPF ISA V4 introduces sign-extending move and load operations. This
patch makes the BPF backend generate those instructions, when enabled
and useful.
A new option, -m[no-]smov gates generation of these instructions, and is
enabled by default for -mcpu=v4 and above. Tests for the new
This patch makes some minor cleanups to eBPF options documented in
invoke.texi:
- Delete some vestigal docs for removed -mkernel option
- Add -mbswap and -msdiv to the option summary
- Note the negative versions of several options
- Note that -mcpu=v4 also enables -msdiv.
gcc/
*
The pseudo-C output templates for these instructions were incorrectly
using operand 1 rather than operand 2 on the RHS, which led to some
very incorrect assembly generation with -masm=pseudoc.
Tested on bpf-unknown-none.
OK?
gcc/
* config/bpf/bpf.md (add3): Use %w2 instead of %w1
[Changes from v1: save calls to fprintf]
Unfortunately, the pseudo-C dialect syntax used for some of the v3
atomic instructions clashes with unconditionally printing the
surrounding parentheses in bpf_print_operand_address.
Instead, place the parentheses in the output templates where needed.
[Changes from v1: fix merge issue in invoke.texi]
This patch adds support for the general atomic operations introduced in
eBPF v3. In addition to the existing atomic add instruction, this adds:
- Atomic and, or, xor
- Fetching versions of these operations (including add)
- Atomic exchange
-
On 7/25/23 15:14, Jose E. Marchesi wrote:
>
> Hi David.
>
>> Unfortunately, the pseudo-C dialect syntax used for some of the v3
>> atomic instructions clashes with unconditionally printing the
>> surrounding parentheses in bpf_print_operand_address.
>>
>> Instead, place the parentheses in the
On 7/25/23 15:18, Jose E. Marchesi wrote:
>
> Hi David.
>
>> +<<< HEAD
>
> There is a merge problem there.
Ugh, I swear I've fixed this twice now. Yet it keeps cropping up.
Sorry. v2 shortly.
>
>> @opindex mbswap
>> @item -mbswap
>> Enable byte swap instructions. Enabled for CPU
This patch adds support for the general atomic operations introduced in
eBPF v3. In addition to the existing atomic add instruction, this adds:
- Atomic and, or, xor
- Fetching versions of these operations (including add)
- Atomic exchange
- Atomic compare-and-exchange
To control emission of
Unfortunately, the pseudo-C dialect syntax used for some of the v3
atomic instructions clashes with unconditionally printing the
surrounding parentheses in bpf_print_operand_address.
Instead, place the parentheses in the output templates where needed.
Tested in bpf-unknown-none.
OK?
gcc/
The define_insn "nop" was missing a template for the pseudo-c dialect,
so the normal syntax was unconditionally emitted.
Tested on bpf-unknown-none, committed as obvious.
gcc/
* config/bpf/bpf.md (nop): Add pseudo-c asm dialect template.
---
gcc/config/bpf/bpf.md | 2 +-
1 file
Gentle ping.
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624156.html
On 7/11/23 14:57, David Faust via Gcc-patches wrote:
> Hello,
>
> This series adds support for a new attribute, "btf_decl_tag" in GCC.
> The same attribute is already supported in clang,
Hi Cupertino,
On 7/21/23 09:43, Cupertino Miranda wrote:
> gcc/ChangeLog:
>
> * config/bpf/bpf.md: fixed template for neg instruction.
> ---
> gcc/config/bpf/bpf.md | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/bpf/bpf.md b/gcc/config/bpf/bpf.md
>
mponent in the kernel (pahole).]
>>>
>>> Hi Richard.
>>>
>>>> On Tue, Jul 11, 2023 at 11:58 PM David Faust via Gcc-patches
>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> This series adds suppor
This patch updates btfout.cc to be aware of BTF_KIND_DECL_TAG types and
output them appropriately.
gcc/
* btfout.cc (funcs_map): New hash map.
(btf_emit_preprocess): ... Initialize it here...
(btf_collect_datasec): ... Populate it here...
(btf_finalize): ... And
Add the "btf_decl_tag" attribute to the attribute table, along with
a simple handler for it.
gcc/c-family/
* c-attribs.cc (c_common_attribute_table): Add btf_decl_tag.
(handle_btf_decl_tag_attribute): Handle new attribute.
---
gcc/c-family/c-attribs.cc | 23
This patch adds tests for the btf_decl_tag attribute, in both DWARF
and BTF.
gcc/testsuite/
* gcc.dg/debug/btf/btf-decltag-func.c: New test.
* gcc.dg/debug/btf/btf-decltag-sou.c: New test.
* gcc.dg/debug/btf/btf-decltag-var.c: New test.
*
This patch makes the DWARF-to-CTF conversion process aware of the new
DW_TAG_GNU_annotation DIEs. The DIEs are converted to CTF_K_DECL_TAG
types and added to the compilation unit CTF container to be translated
to BTF and output.
gcc/
* dwarf2ctf.cc (handle_btf_tags): New function.
Add documentation for the btf_decl_tag attribute.
gcc/
* doc/extend.texi (Common Function Attributes): Document btf_decl_tag.
(Common Variable Attributes): Likewise.
---
gcc/doc/extend.texi | 47 +
1 file changed, 47 insertions(+)
Expose get_die_parent () so it can be used outside of dwarf2out.cc
gcc/
* dwarf2out.cc (get_die_parent): Make non-static.
* dwarf2out.h (get_die_parent): Add extern declaration here.
---
gcc/dwarf2out.cc | 2 +-
gcc/dwarf2out.h | 1 +
2 files changed, 2 insertions(+), 1
The "btf_decl_tag" attribute is handled by constructing a
DW_TAG_GNU_annotation DIE for each occurrence to record the argument
string in debug information. The DIEs are children of the declarations
they annotate, with the following format:
DW_TAG_GNU_annotation
DW_AT_name "btf_decl_tag"
BTF generation currently relies on the internal CTF representation to
convert debug info from DWARF dies. This patch adds a new internal
header, "ctf-int.h", which defines CTF kinds to be used internally to
represent BTF tags which must pass through the CTF container. It also
adds a new type for
1 - 100 of 208 matches
Mail list logo
