public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/112656] New: btf: function prototypes generated with name
@ 2023-11-21 19:25 jemarch at gcc dot gnu.org
  2023-11-21 19:37 ` [Bug debug/112656] " jemarch at gcc dot gnu.org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: jemarch at gcc dot gnu.org @ 2023-11-21 19:25 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656

            Bug ID: 112656
           Summary: btf: function prototypes generated with name
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jemarch at gcc dot gnu.org
  Target Milestone: ---

BTF suports both BTF_KIND_FUNC and BTF_KIND_FUNC_PROTO tags.  FUNC entries link
to their corresponding PROTO via type_id.  PROTO entries must have no names,
i.e. name_off shall be 0.

GCC seems to be generating non-anonymous BTF_KIND_FUNC_PROTO entries in some
circumstances:

$ bpf-unknown-none-gcc -c -O2 repro.i -o repro.o
$ bpftool btf dump all | grep FUNC_PROTO | grep -v anon
[8319] FUNC_PROTO '____kretprobe_ieee80211_get_channel_khz' ret_type_id=7
vlen=2
[8321] FUNC_PROTO '____kprobe_ieee80211_scan_completed' ret_type_id=7 vlen=2
[8333] FUNC_PROTO '____kprobe_ieee80211_request_scan' ret_type_id=7 vlen=2
[8343] FUNC_PROTO '____kprobe_unregister_netdev' ret_type_id=7 vlen=2
[8345] FUNC_PROTO '____kprobe_register_netdev' ret_type_id=7 vlen=2
[8347] FUNC_PROTO '____kprobe_ieee80211_unregister_hw' ret_type_id=7 vlen=1
[8349] FUNC_PROTO '____kprobe_ieee80211_register_hw' ret_type_id=7 vlen=1
[8351] FUNC_PROTO 'log_event' ret_type_id=0 vlen=2

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug debug/112656] btf: function prototypes generated with name
  2023-11-21 19:25 [Bug debug/112656] New: btf: function prototypes generated with name jemarch at gcc dot gnu.org
@ 2023-11-21 19:37 ` jemarch at gcc dot gnu.org
  2023-11-21 19:45 ` jemarch at gcc dot gnu.org
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: jemarch at gcc dot gnu.org @ 2023-11-21 19:37 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656

--- Comment #1 from Jose E. Marchesi <jemarch at gcc dot gnu.org> ---
Smaller reproducer:

  static void log_event(const char *event_name, void *dev_ptr)
  {
  }

  void lala ()
  {
    log_event ("foobar", ((void *)0));
  }

Note that the FUNC_PROTO for log_event seems to be created with a name only if
the function gets inlined:

$ bpf-unknown-none-gcc -gbtf -c -O2 foo.c -o foo.o
$ bpftool btf dump file foo.o
[1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[2] FUNC_PROTO '(anon)' ret_type_id=1 vlen=0
[3] FUNC_PROTO 'log_event' ret_type_id=1 vlen=2
        'event_name' type_id=6
        'dev_ptr' type_id=7
[4] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED
[5] CONST '(anon)' type_id=4
[6] PTR '(anon)' type_id=5
[7] PTR '(anon)' type_id=0
[8] FUNC 'lala' type_id=2 linkage=global

$ bpf-unknown-none-gcc -gbtf -c -O2 -fno-inline foo.c -o foo.o
$ /usr/sbin/bpftool btf dump file foo.o
[1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[2] FUNC_PROTO '(anon)' ret_type_id=1 vlen=0
[3] FUNC_PROTO '(anon)' ret_type_id=1 vlen=2
        'event_name' type_id=6
        'dev_ptr' type_id=7
[4] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED
[5] CONST '(anon)' type_id=4
[6] PTR '(anon)' type_id=5
[7] PTR '(anon)' type_id=0
[8] FUNC 'lala' type_id=2 linkage=global
[9] FUNC 'log_event' type_id=3 linkage=static

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug debug/112656] btf: function prototypes generated with name
  2023-11-21 19:25 [Bug debug/112656] New: btf: function prototypes generated with name jemarch at gcc dot gnu.org
  2023-11-21 19:37 ` [Bug debug/112656] " jemarch at gcc dot gnu.org
@ 2023-11-21 19:45 ` jemarch at gcc dot gnu.org
  2023-11-21 20:37 ` jemarch at gcc dot gnu.org
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: jemarch at gcc dot gnu.org @ 2023-11-21 19:45 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656

--- Comment #2 from Jose E. Marchesi <jemarch at gcc dot gnu.org> ---
The btf_collect_datasec function in btf2out.cc traverses the cgraph and, for
each function, transforms its CTF_K_FUNCTION into a pair of BTF_KIND_FUNC_PROTO
and BTF_KIND_FUNC.  But if the function is inlined I don't think the
transformation is performed.  Thats probably why no BTF_KIND_FUNC is generated
for the function with inline enabled.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug debug/112656] btf: function prototypes generated with name
  2023-11-21 19:25 [Bug debug/112656] New: btf: function prototypes generated with name jemarch at gcc dot gnu.org
  2023-11-21 19:37 ` [Bug debug/112656] " jemarch at gcc dot gnu.org
  2023-11-21 19:45 ` jemarch at gcc dot gnu.org
@ 2023-11-21 20:37 ` jemarch at gcc dot gnu.org
  2023-11-27 21:43 ` ibhagat at gcc dot gnu.org
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: jemarch at gcc dot gnu.org @ 2023-11-21 20:37 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656

--- Comment #3 from Jose E. Marchesi <jemarch at gcc dot gnu.org> ---
clang does not emit BTF FUNC nor FUNC_PROTO entries for inlined functions.  So
the fix is probably to not emit CTF_K_FUNCTION entries that have not been
handled in the FOR_EACH_FUNCTION loop.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug debug/112656] btf: function prototypes generated with name
  2023-11-21 19:25 [Bug debug/112656] New: btf: function prototypes generated with name jemarch at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2023-11-21 20:37 ` jemarch at gcc dot gnu.org
@ 2023-11-27 21:43 ` ibhagat at gcc dot gnu.org
  2023-11-27 21:53 ` ibhagat at gcc dot gnu.org
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: ibhagat at gcc dot gnu.org @ 2023-11-27 21:43 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656

Indu Bhagat <ibhagat at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibhagat at gcc dot gnu.org

--- Comment #4 from Indu Bhagat <ibhagat at gcc dot gnu.org> ---
Noted that the issue is not repeatable on x86_64.

$ cat foo.c
static int log_event(const char *event_name, void *dev_ptr)
{
  return 666;
}

int foo ()
{
  return log_event ("foobar", ((void *)0));
}

$ gcc  -O2  -gbtf -c foo.c

$ bpftool btf dump file foo.o
[1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[2] FUNC_PROTO '(anon)' ret_type_id=1 vlen=0
[3] FUNC_PROTO '(anon)' ret_type_id=1 vlen=2
        'event_name' type_id=6
        'dev_ptr' type_id=7
[4] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED
[5] CONST '(anon)' type_id=4
[6] PTR '(anon)' type_id=5
[7] PTR '(anon)' type_id=0
[8] FUNC 'foo' type_id=2 linkage=global
[9] FUNC 'log_event' type_id=3 linkage=static

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug debug/112656] btf: function prototypes generated with name
  2023-11-21 19:25 [Bug debug/112656] New: btf: function prototypes generated with name jemarch at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2023-11-27 21:43 ` ibhagat at gcc dot gnu.org
@ 2023-11-27 21:53 ` ibhagat at gcc dot gnu.org
  2023-11-28  5:15 ` jemarch at gcc dot gnu.org
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: ibhagat at gcc dot gnu.org @ 2023-11-27 21:53 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656

--- Comment #5 from Indu Bhagat <ibhagat at gcc dot gnu.org> ---
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. See
ctf_debug_early_finish:

void
ctf_debug_early_finish (const char * filename)
{
  /* Emit CTF debug info early always.  */
  if (ctf_debug_info_level > CTFINFO_LEVEL_NONE
      /* Emit BTF debug info early if CO-RE relocations are not
         required.  */
      || (btf_debuginfo_p () && !btf_with_core_debuginfo_p ()))
    ctf_debug_finalize (filename, btf_debuginfo_p ());
}

For posterity - In summary, it cannot be assumed that BTF generated for BPF
target will be same as that generated for x86_64, at least until -mco-re is the
default.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug debug/112656] btf: function prototypes generated with name
  2023-11-21 19:25 [Bug debug/112656] New: btf: function prototypes generated with name jemarch at gcc dot gnu.org
                   ` (4 preceding siblings ...)
  2023-11-27 21:53 ` ibhagat at gcc dot gnu.org
@ 2023-11-28  5:15 ` jemarch at gcc dot gnu.org
  2023-11-29 19:07 ` ibhagat at gcc dot gnu.org
  2023-12-04 10:01 ` cvs-commit at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: jemarch at gcc dot gnu.org @ 2023-11-28  5:15 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656

Jose E. Marchesi <jemarch at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david.faust at oracle dot com

--- Comment #6 from Jose E. Marchesi <jemarch at gcc dot gnu.org> ---
Doesn't this mean that we have to split the BTF generation in two parts? 
First, at early_finish(), then again at finish() if -mco-re is used?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug debug/112656] btf: function prototypes generated with name
  2023-11-21 19:25 [Bug debug/112656] New: btf: function prototypes generated with name jemarch at gcc dot gnu.org
                   ` (5 preceding siblings ...)
  2023-11-28  5:15 ` jemarch at gcc dot gnu.org
@ 2023-11-29 19:07 ` ibhagat at gcc dot gnu.org
  2023-12-04 10:01 ` cvs-commit at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: ibhagat at gcc dot gnu.org @ 2023-11-29 19:07 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656

--- Comment #7 from Indu Bhagat <ibhagat at gcc dot gnu.org> ---
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 the source-level data
structures, e.g. "0:4:2:3", and are stored int the .BTF string table.  CO-RE is
handled in the BPF backend during expand, which is after debug_early_finish ().

'Whether we should split BTF generation into two parts' is a larger question
not affecting the current PR at hand, I think. We should evaluate the overall
benefit of that approach (apart from the one we are seeing here - reproducible
BTF across targets), vs the implementation cost and complexity. If there is
interest.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug debug/112656] btf: function prototypes generated with name
  2023-11-21 19:25 [Bug debug/112656] New: btf: function prototypes generated with name jemarch at gcc dot gnu.org
                   ` (6 preceding siblings ...)
  2023-11-29 19:07 ` ibhagat at gcc dot gnu.org
@ 2023-12-04 10:01 ` cvs-commit at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-12-04 10:01 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656

--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Indu Bhagat <ibhagat@gcc.gnu.org>:

https://gcc.gnu.org/g:b6abc5dbfa5342347828b9feb4d9060071ff819c

commit r14-6112-gb6abc5dbfa5342347828b9feb4d9060071ff819c
Author: Indu Bhagat <indu.bhagat@oracle.com>
Date:   Mon Dec 4 01:57:34 2023 -0800

    BTF: fix PR debug/112656

    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 types output varies across targets (BPF with -mco-re
    vs non-BPF targets).  Hence the check in the test case merely checks
    that all BTF_KIND_FUNC_PROTO appear anonymous.

    gcc/ChangeLog:

            PR debug/112656
            * btfout.cc (btf_asm_type): Fixup ctti_name for all
            BTF types of kind BTF_KIND_FUNC_PROTO.

    gcc/testsuite/ChangeLog:

            PR debug/112656
            * gcc.dg/debug/btf/btf-function-7.c: New test.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2023-12-04 10:01 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-21 19:25 [Bug debug/112656] New: btf: function prototypes generated with name jemarch at gcc dot gnu.org
2023-11-21 19:37 ` [Bug debug/112656] " jemarch at gcc dot gnu.org
2023-11-21 19:45 ` jemarch at gcc dot gnu.org
2023-11-21 20:37 ` jemarch at gcc dot gnu.org
2023-11-27 21:43 ` ibhagat at gcc dot gnu.org
2023-11-27 21:53 ` ibhagat at gcc dot gnu.org
2023-11-28  5:15 ` jemarch at gcc dot gnu.org
2023-11-29 19:07 ` ibhagat at gcc dot gnu.org
2023-12-04 10:01 ` cvs-commit at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).