[Bug debug/97060] New: Missing DW_AT_declaration=1 in dwarf data

[jolsa at redhat dot com]

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

Bug ID: 97060
   Summary: Missing DW_AT_declaration=1 in dwarf data
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jolsa at redhat dot com
  Target Milestone: ---

We are missing expected declaration tag - DW_AT_declaration : 1 for function
in debug info data.

The problem we see is:

 - fs/init.c calls vfs_getattr function
 - vfs_getattr is defined outside the fs/init.c
 - once compiled, debug info data for vfs_getattr should contain declaration
   tag - DW_AT_declaration : 1, but it's missing

gcc version: gcc (GCC) 10.2.1 20200826 (Red Hat 10.2.1-3)

Unfortunately the issue can be so far reproduced only inside container,
I tried to narrow it down to single fs/init.o object.

Following steps create fs/init.o binary in kernel tree within the container:

# podman image pull
registry.gitlab.com/cki-project/containers/builder-rawhide:latest
# podman image list
# podman run -it  /bin/bash
# git clone https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
--depth 1
# curl
https://xci32.lab.eng.rdu2.redhat.com/cki-project/cki-pipeline/-/jobs/974002/artifacts/raw/artifacts/kernel-bpf-next-x86_64-cd04b04de119a222c83936f7e9dbd46a650cb688.config
-o bpf-next/.config
# cd bpf-next/

# make oldconfig # might need some ENTERs
# make fs/ -j

# gcc -Wp,-MMD,fs/.init.o.d -nostdinc -isystem
/usr/lib/gcc/x86_64-redhat-linux/10/include -I./arch/x86/include
-I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi
-I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi
-include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h
-D__KERNEL__ -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE
-Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security
-std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1
-falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3
-mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare
-fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern
-mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks
-Wno-frame-address -Wno-format-truncation -Wno-format-overflow
-Wno-address-of-packed-member -O2 -fno-allow-store-data-races
-Wframe-larger-than=2048 -fstack-protector -Wno-unused-but-set-variable
-Wimplicit-fallthrough -Wno-unused-const-variable -fno-var-tracking-assignments
-g -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -flive-patching=inline-clone
-Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation
-Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict
-Wno-maybe-uninitialized -fno-strict-overflow -fno-merge-all-constants
-fmerge-constants -fno-stack-check -fconserve-stack -Werror=date-time
-Werror=incompatible-pointer-types -Werror=designated-init
-fmacro-prefix-map=./= -fcf-protection=none -Wno-packed-not-aligned   
-DKBUILD_MODFILE='"fs/init"' -DKBUILD_BASENAME='"init"'
-DKBUILD_MODNAME='"init"' -c -o fs/init.o fs/init.c

# readelf --debug fs/init.o
...
 <1><9145>: Abbrev Number: 46 (DW_TAG_subprogram)
<9146>   DW_AT_external: 1
<9146>   DW_AT_name: (indirect string, offset: 0x531c): vfs_getattr
<914a>   DW_AT_decl_file   : 7
<914b>   DW_AT_decl_line   : 3148
<914d>   DW_AT_decl_column : 12
<914e>   DW_AT_prototyped  : 1
<914e>   DW_AT_type: <0xa9>
<9152>   DW_AT_sibling : <0x916b>
 <2><9156>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<9157>   DW_AT_type: <0x3573>
 <2><915b>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<915c>   DW_AT_type: <0x893a>
 <2><9160>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<9161>   DW_AT_type: <0x111>
 <2><9165>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<9166>   DW_AT_type: <0x4c>


When we link the final kernel binary the debug info data contains multiple
records for vfs_getattr,
and neither has 'declaration' tag and it confuses pahole tool that uses this
data to get function
records and skips declarations.

The problem is for more functions, vfs_getattr is just one example.

[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data

[jolsa at redhat dot com]

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

--- Comment #2 from Jiri Olsa  ---
Created attachment 49223
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49223&action=edit
fs/init.i

[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data

[jolsa at redhat dot com]

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

--- Comment #4 from Jiri Olsa  ---
(In reply to Jakub Jelinek from comment #3)
> So this is really just something like: -O2 -g -dA:
> extern int foo (unsigned int, unsigned int);
> 
> int
> bar (void)
> {
>   foo (1, 2);
>   return 0;
> }
> 
> where we don't emit DW_AT_declaration neither for the external declaration
> of foo, nor for the definition of bar.  Other compilers don't emit them
> either.
> 
> Anyway, older gcc versions used to emit those and this changed with
> PR96383 r11-2455-gc6ef9d8d3f11221df1ea6358b8d4e79e42f074fb

is there a way we can tell which record is for declaration/definition?

[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data

[jolsa at redhat dot com]

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

--- Comment #9 from Jiri Olsa  ---
(In reply to Jakub Jelinek from comment #6)
> Also, to avoid confusion, upstream 10 branch is not affected, but in 10-RH
> we've backported the PR96383 changes from the trunk.

Is this gcc going to RHEL8? that could be a problem for us.

Also, is there a way how we can workaround this?

How to recgnize function declaration apart from
definition in dwarf data?

[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data

[jolsa at redhat dot com]

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

--- Comment #11 from Jiri Olsa  ---
(In reply to Jakub Jelinek from comment #10)
> RHEL8 uses gcc 8 which is not affected (unless one uses DTS/GTS).
> Also, it is unclear for what in particular pahole or what wants to use
> DW_AT_declaration.

pahole takes dwarf data and produces BTF type data
that includes functions

the DW_AT_declaration flag was used to skip function
declarations so only one function record was processed
and added to BTF data

without that flag pahole will add one function multiple
times to BTF data, based on how many times it was declared
in other objects

> DW_TAG_subprogram of a real definition (that hasn't been optimized out) is
> the one that has DW_AT_low_pc/DW_AT_high_pc or DW_AT_ranges attributes (i.e.
> has any associated code).  Some functions can have many definitions (e.g.
> inline functions or other comdat entities).

I'll check if we can add more check to pahole for this

thanks

[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data

[jolsa at redhat dot com via Gcc-bugs]

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

--- Comment #13 from Jiri Olsa  ---
hi,
any update on the fix? I'm seeing the bug now in fedora 32 with:

  $ gcc --version
  gcc (GCC) 10.2.1 20201005 (Red Hat 10.2.1-5)


thanks,
jirka