public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "lvlin at mail dot ustc.edu.cn" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/98776] New: DW_AT_low_pc is inconsistent with function entry address, when enabling -fpatchable-function-entry
Date: Thu, 21 Jan 2021 06:32:16 +0000	[thread overview]
Message-ID: <bug-98776-4@http.gcc.gnu.org/bugzilla/> (raw)

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

            Bug ID: 98776
           Summary: DW_AT_low_pc is inconsistent with function entry
                    address, when enabling -fpatchable-function-entry
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lvlin at mail dot ustc.edu.cn
  Target Milestone: ---
            Target: x86,arm64

-fpatchable-function-entry will generate N NOPs at the beginning of each
function. Observe the binary compiled by gcc, the function entry address is
inconsistent with the value of DW_AT_low_pc in the corresponding DWARF data.

I used a toy example to describe the issue;

1.Compile the source file toy_exam.c 
        $ gcc -o toy_exam.gcc toy_exam.c  -g -gdwarf-4
-fpatchable-function-entry=2 -save-temps

2.Check the symbolic address of the function fun_a
        $ readelf -s  toy_exam.gcc  |grep -w fun_a
    95: 00000000000007f0    80 FUNC    GLOBAL DEFAULT   13 fun_a

3.Display assembler contents
        objdump -d toy_exam.gcc |grep -A 8  -w \<fun_a\>:
00000000000007f0 <fun_a>:
 7f0:   d503201f        nop
 7f4:   d503201f        nop
 7f8:   a9be7bfd        stp     x29, x30, [sp, #-32]!
 7fc:   910003fd        mov     x29, sp
 800:   52800040        mov     w0, #0x2                        // #2
 804:   b90017e0        str     w0, [sp, #20]
 808:   528000a0        mov     w0, #0x5                        // #5
 80c:   b9001be0        str     w0, [sp, #24]

4.dump dwarf info
        $ llvm-dwarfdump toy_exam.gcc  |grep -C 10 -w fun_a
0x00000315:   DW_TAG_subprogram
                DW_AT_external  (true)
                DW_AT_name      ("fun_a")
                DW_AT_decl_file ("/home/jianlin/code/test/toy_exam.c")
                DW_AT_decl_line (14)
                DW_AT_decl_column       (0x06)
                DW_AT_low_pc    (0x00000000000007f8)
                DW_AT_high_pc   (0x0000000000000840)
                DW_AT_frame_base        (DW_OP_call_frame_cfa)
                DW_AT_GNU_all_tail_call_sites   (true)
                DW_AT_sibling   (0x0000035d)

5. Assembler code
fun_a:
        .section        __patchable_function_entries
        .8byte  .LPFE2
        .text
.LPFE2:
        nop
        nop
.LFB7:
        .loc 1 15 1
        .cfi_startproc
        stp     x29, x30, [sp, -32]!
        .cfi_def_cfa_offset 32
        .cfi_offset 29, -32
        .cfi_offset 30, -24
        mov     x29, sp
        .loc 1 16 13

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/gcc-trunk/libexec/gcc/aarch64-unknown-linux-gnu/11.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/gcc-trunk
--enable-languages=c,c++,fortran --disable-libquadmath
--disable-libquadmath-support --disable-werror --disable-bootstrap
--enable-gold
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20210119 (experimental) (GCC)


the first instruction in the compile unit indicated by DW_AT_low_pc does not
include NOP.


GCC-9, GCC-10 and the latest master branch were respectively tested, and the
results were the same.

             reply	other threads:[~2021-01-21  6:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-21  6:32 lvlin at mail dot ustc.edu.cn [this message]
2021-03-31 10:21 ` [Bug debug/98776] " rearnsha at gcc dot gnu.org
2021-06-29 17:06 ` luis.machado at linaro dot org
2021-06-30  6:28 ` rguenth at gcc dot gnu.org
2021-06-30  6:28 ` rguenth at gcc dot gnu.org
2021-06-30  7:12 ` marxin at gcc dot gnu.org
2021-06-30  8:06 ` rguenth at gcc dot gnu.org
2021-06-30  8:20 ` marxin at gcc dot gnu.org
2021-06-30  8:27 ` rguenth at gcc dot gnu.org
2022-09-29 20:50 ` spop at gcc dot gnu.org
2022-12-01  3:11 ` spop at gcc dot gnu.org
2022-12-08 17:12 ` cvs-commit at gcc dot gnu.org
2022-12-15 15:08 ` cvs-commit at gcc dot gnu.org
2022-12-15 15:10 ` cvs-commit at gcc dot gnu.org
2022-12-15 15:12 ` cvs-commit at gcc dot gnu.org
2022-12-15 15:15 ` spop at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-98776-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).