https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117289
--- Comment #4 from Indu Bhagat ---
On the BTF side, we will see an additional BTF type too with -std=gnu23 (as
expected because BTF generation is based off CTF internally in GCC):
$ bpftool btf dump file ctf-function-pointers-2.o
[1] STRUCT 'c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117289
--- Comment #2 from Indu Bhagat ---
Regarding handling of duplicate types in CTF, the bulk of expectation lies on
the link-time de-duplication. On the compiler side, we simply try to not emit
duplicate CTF types to avoid bloating up the object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112878
--- Comment #5 from Indu Bhagat ---
Hmm, thanks. Using sorry in some cases will be a viable option.
For this specific case though, I am thinking emitting CTF_K_UNKNOWN instead
should be okay. We have precedent in CTF generation in GCC where if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112878
--- Comment #3 from Indu Bhagat ---
The limit of 255 is somewhat arbitrary but we need to follow it for now,
because libctf has a check in ctf_add_slice () in libctf/ctf-create.c :
if ((ep->cte_bits > 255) || (ep->cte_offset > 255))
retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112768
Indu Bhagat changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114186
Indu Bhagat changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114186
--- Comment #1 from Indu Bhagat ---
This in turn affects BTF generation too, because GCC internally uses the CTFC
(CTF container) to create BTF info.
$ bpftool btf dump file array.o
[1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114186
Bug ID: 114186
Summary: Incorrect CTF generated for multidimensional array
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112849
--- Comment #2 from Indu Bhagat ---
I think its also a good idea to propose a patch to btf.rst upstream to clearly
state something to the like of:
- What variables have an associated BTF_KIND_DATASEC entry
- In "2.2.15 BTF_KIND_DATASEC"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112768
Indu Bhagat changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112768
Bug ID: 112768
Summary: btf: fix asm comment output for BTF_KIND_FUNC* kinds
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656
--- Comment #7 from Indu Bhagat ---
Currently generating everything at finish () when -mco-re is in effect is
sufficient for BPF needs. BTF is generated late for -mco-re because of CO-RE
relocations: these are strings which record indexes into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656
--- Comment #5 from Indu Bhagat ---
The reason for the noted difference in BTF for BPF vs non-BPF target is:
On non-BPF targets, BTF is emitted in early_finish. On BPF target however,
-mco-re is default, and hence, BTF is emitted in late finish
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656
Indu Bhagat changed:
What|Removed |Added
CC||ibhagat at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109161
--- Comment #3 from Indu Bhagat ---
Excerpt from the generated DWARF debug info:
<1><32>: Abbrev Number: 3 (DW_TAG_subprogram)
<33> DW_AT_external: 1
<33> DW_AT_name: (indirect string, offset: 0x12c4): set_cpu_arch
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105089
Indu Bhagat changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109161
Bug ID: 109161
Summary: Bad CTF generated for stub in function scope
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: deb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106263
Bug ID: 106263
Summary: BTF_KIND_FUNC type does not encode linkage
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105636
--- Comment #2 from Indu Bhagat ---
I found the minimum reproducer to be:
$ cat testcase.c
static int sa[100];
int n;
static int (*a2)[] = (__typeof__(int (*)[n]))sa;
I tried to debug this and found out that the likely cause is some invalidit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105636
--- Comment #1 from Indu Bhagat ---
Thank you for reporting this. I can reproduce it, nice and easy :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105089
--- Comment #5 from Indu Bhagat ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Indu Bhagat from comment #2)
> > Regarding this above-mentioned case of two variables (one inside the
> > function), CTF emits debug information for f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105089
--- Comment #3 from Indu Bhagat ---
Re: the more "specific" one?, I think if the compiler picks the type from the
defining declaration of the variable, that will be useful (and correct I think)
CTF debug information.
So, for the following-
cas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105089
--- Comment #2 from Indu Bhagat ---
Regarding this above-mentioned case of two variables (one inside the function),
CTF emits debug information for file-scope and global-scope variables only. So
in this example, the declaration of a inside the f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105089
Bug ID: 105089
Summary: CTF for a defined extern variable is ambiguous
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102507
Indu Bhagat changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102507
Indu Bhagat changed:
What|Removed |Added
CC||ibhagat at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283
Indu Bhagat changed:
What|Removed |Added
CC||ibhagat at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102507
Indu Bhagat changed:
What|Removed |Added
Last reconfirmed||2021-09-27
Assignee|unassigned
28 matches
Mail list logo
