bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/30692] New: [RISC-V] Symbol offset in .eh_frame section is


From: yanzhang.wang at intel dot com
Subject: [Bug binutils/30692] New: [RISC-V] Symbol offset in .eh_frame section is not adjusted after relaxation
Date: Fri, 28 Jul 2023 06:07:59 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=30692

            Bug ID: 30692
           Summary: [RISC-V] Symbol offset in .eh_frame section is not
                    adjusted after relaxation
           Product: binutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: yanzhang.wang at intel dot com
  Target Milestone: ---

When we build the test with option -static -pg, the binary will be segment
fault. This is also a block issue to enable -static-pie for us.

» cat hello.c
int main(void)
{
        return 0;
}

» riscv64-unknown-linux-gnu-gcc -static -pg hello.c

(gdb) r
Starting program: /home/riscv/a.out

Program received signal SIGSEGV, Segmentation fault.
classify_object_over_fdes (ob=0x82320 <object>, this_fde=0x100051fba,
range=0x3ffffff380)
    at ../../.././gcc/libgcc/unwind-dw2-fde.c:727
727     ../../.././gcc/libgcc/unwind-dw2-fde.c: No such file or directory.
(gdb) bt
#0  classify_object_over_fdes (ob=0x82320 <object>, this_fde=0x100051fba,
range=0x3ffffff380)
    at ../../.././gcc/libgcc/unwind-dw2-fde.c:727
#1  0x00000000000513ee in __register_frame_info_bases (dbase=0x0, tbase=0x0,
ob=0x82320 <object>,
    begin=<optimized out>) at ../../.././gcc/libgcc/unwind-dw2-fde.c:129
#2  __register_frame_info_bases (dbase=0x0, tbase=0x0, ob=0x82320 <object>,
begin=<optimized out>)
    at ../../.././gcc/libgcc/unwind-dw2-fde.c:109
#3  __register_frame_info (begin=<optimized out>, ob=0x82320 <object>)
    at ../../.././gcc/libgcc/unwind-dw2-fde.c:145
#4  0x00000000000106d8 in frame_dummy ()
#5  0x0000000000010980 in __libc_start_main_impl ()
#6  0x00000000000105e8 in _start ()


The root cause is the variable __EH_FRAME_BEGIN__ defined in .eh_frame section
has wrong value. Some objdump's output,

00000000000106b6 <frame_dummy>:
   106b6:       000517b7                lui     a5,0x51
   106ba:       3c278793                add     a5,a5,962 # 513c2
<__register_frame_info>
   106be:       c385                    beqz    a5,106de <frame_dummy+0x28>
   106c0:       000825b7                lui     a1,0x82
   106c4:       0006e537                lui     a0,0x6e
   106c8:       1141                    add     sp,sp,-16
   106ca:       32058593                add     a1,a1,800 # 82320 <object.0>
   106ce:       0e050513                add     a0,a0,224 # 6e0e0
<__EH_FRAME_BEGIN__>

Disassembly of section .eh_frame:

000000000006e0f0 <__EH_FRAME_BEGIN__+0x10>:

On x86 and ARM, it seems the reference of __EH_FRAME_BEGIN__ will be converted
to section with offset in gas. But on RISC-V, because tc_fix_adjustable was
disabled, so the symbol will not be adjusted.

If we dive deeper, the wrong value comes from the relaxation. The local symbols
in .eh_frame will be adjusted in bfd_elf_discard_info, but will not be adjusted
when and after relaxation. For example, before relaxation, the symbol will be
offset 0x50 due to the alignment requirement; after relaxation, the offset will
be 0x40 because no need to align. That's why .eh_frame start is the
__EH_FRAME_BEGIN__ + 0x10.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]