Bug 2092438

Summary: wrong function entry listed in debuginfo with -fpatchable-function-entry
Product: Red Hat Enterprise Linux 9 Reporter: William Cohen <wcohen>
Component: gccAssignee: Marek Polacek <mpolacek>
gcc sub component: system-version QA Contact: qe-baseos-tools-bugs
Status: CLOSED UPSTREAM Docs Contact:
Severity: medium    
Priority: unspecified CC: ahajkova, fweimer, jakub, ohudlick, sipoyare
Version: 9.0   
Target Milestone: rc   
Target Release: ---   
Hardware: aarch64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-06-02 14:41:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2087087    
Attachments:
Description Flags
Tarball showing the issue with -fpatchable-function-entry on aarch64 none

Description William Cohen 2022-06-01 14:29:15 UTC 
Created attachment 1885810 [details]
Tarball showing the issue with -fpatchable-function-entry on aarch64

Description of problem:
When the  -fpatchable-function-entry is used the debuginfo indicates that the function starts after the nop instructions inserted at the beginning of the function.  This issue looks very similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103525


Version-Release number of selected component (if applicable):
gcc-11.2.1-9.4.el9.aarch64

How reproducible: every time


Steps to Reproduce:
1. Download the gcc_patchable.tar.gz in this bug
2. tar xvfz ./gcc_patchable.tar.gz 
3. cd gcc_patchable
4. gcc -fpatchable-function-entry=8 -g -O2 -save-temps u32_test.c -o u32_test
5. llvm-dwarfdump  --name="main" u32_test
6. nm u32_test |grep main


Actual results:
The nm states that the function starts at 0000000000400580, but the DW_AT_low_pc states it starts later at 0x00000000004005a0




Expected results:
The DW_AT_low_pc and start of the function reported by nm should match.


Additional info:

This issue was observed  because the RHEL kernels are compiled with 
CONFIG_DYNAMIC_FTRACE_WITH_REGS=y.

One of the comments, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103525#c2 , mentions that a similar issue was addressed on x86_64.
Comment 1 Marek Polacek 2022-06-02 14:41:02 UTC 
I've updated PR103525 but it's been in NEW for 6 months, so I think this is not going to be fixed anytime soon.  So it seems appropriate to track this upstream only.