Bug 28098 - Linking with with libcudart_static.a produces an empty eh_frame_hdr section
Summary: Linking with with libcudart_static.a produces an empty eh_frame_hdr section
Alias: None
Product: binutils
Classification: Unclassified
Component: gold (show other bugs)
Version: 2.38 (HEAD)
: P2 normal
Target Milestone: 2.38
Assignee: Alan Modra
Depends on:
Reported: 2021-07-17 14:24 UTC by Michael Krasnyk
Modified: 2021-07-18 12:39 UTC (History)
1 user (show)

See Also:
Last reconfirmed: 2021-07-18 00:00:00

add filtering of R_X86_64_NONE entries (740 bytes, patch)
2021-07-17 15:56 UTC, Michael Krasnyk
Details | Diff
updated patch (869 bytes, patch)
2021-07-18 06:53 UTC, Michael Krasnyk
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Krasnyk 2021-07-17 14:24:42 UTC

linking with with libcudart_static.a produces an empty eh_frame_hdr section.

Steps to reproduce:

curl -s https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/cuda-cudart-dev-11-2_11.2.152-1_amd64.deb | dpkg --fsys-tarfile - | tar xOf - ./usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudart_static.a > libcudart_static.a
sha256sum libcudart_static.a
3ca014141258ae33abb175aa88a8282507a04d8a16d8f8dc9340e7831c5831e6  libcudart_static.a

cat > main.c <<EOF
void cudaMalloc();
void main()

gcc main.c -fuse-ld=gold libcudart_static.a -ldl -lrt -pthread && readelf -WS ./a.out | grep eh_frame_hdr
  [17] .eh_frame_hdr     X86_64_UNWIND   00000000000979a4 0979a4 000008 00   A  0   0  4

The section is 
011b ffff 9889 fdff

and bytes 2 and 3 are set to elfcpp::DW_EH_PE_omit.
The flag any_unrecognized_eh_frame_sections_ is set due to the true condition at line

Please could some one point if it is an issue in the static lib, a missing feature in gold linker, or incorrect behavior?

ld.gold --version
GNU gold (GNU Binutils 1.16
git SHA  05b857720611bc2e1f9cca2573085b774181af9d

Michael Krasnyk
Comment 1 Michael Krasnyk 2021-07-17 15:56:45 UTC
Created attachment 13559 [details]
add filtering of R_X86_64_NONE entries

Relocation section '.rela.eh_frame' has an R_X86_64_NONE entry

0000000000013200  0000000a00000002 R_X86_64_PC32          0000000000000000 .text + 5ae80
0000000000013238  0000000000000000 R_X86_64_NONE                             0
0000000000013258  0000001e00000002 R_X86_64_PC32          0000000000000000 .text._ZN15CUOSdlsymLoaderIPFimPKcEED2Ev + 0

Please consider the patch that adds filtering R_X86_64_NONE entries in Track_relocs<size, big_endian>::advance
Comment 2 Alan Modra 2021-07-18 02:50:54 UTC
Thanks for the analysis and patch.  I'm going to ask you to do just a little more work.  First, change the patch to skip r_info==0 relocs, which is R_*_NONE (usually, there are some targets that stupidly define r_type of 0 to be something other than a no-operation relocations) *and* r_sym of zero.  That will match ld.bfd.  Also, put a suitable comment in reloc.h, something like "..would be skipped, excluding r_info==0 relocs." and perhaps expand on this a little in the function comment in reloc.cc, mentioning R_*_NONE and r_sym of zero.  Finally, check over all uses of advance() in gold to see that it isn't used to count relocs for an output array or something like that, which might be broken by your change.  If you get to that point, post the patch to binutils@sourceware.org and I'll commit it.
Comment 4 Michael Krasnyk 2021-07-18 06:53:26 UTC
Created attachment 13561 [details]
updated patch
Comment 5 cvs-commit@gcc.gnu.org 2021-07-18 12:35:55 UTC
The master branch has been updated by Alan Modra <amodra@sourceware.org>:


commit 7c6ff8af98718116c835f46a55b480b9684ea4ef
Author: Michael Krasnyk <mkrasnyk@argo.ai>
Date:   Sat Jul 17 17:35:56 2021 +0200

    PR28098 Skip R_*_NONE relocation entries with zero r_sym without counting
            PR gold/28098
            * reloc.cc (Track_relocs::advance): Skip R_*_NONE relocation entries
            with r_sym of zero without counting in advance method.
Comment 6 Alan Modra 2021-07-18 12:39:52 UTC
Patch applied