Bug 19962

Summary: R_ARM_COPY relocation generated with -znocopyreloc
Product: binutils Reporter: David Crawshaw <david>
Component: ldAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: matz, maxim.kuvyrkov, nickc, rguenth
Priority: P2    
Version: 2.25   
Target Milestone: ---   
Host: Target: arm, aarch64
Build: Last reconfirmed:
Attachments: Proposed patch
Proposed patch

Description David Crawshaw 2016-04-17 15:07:00 UTC 
Linking with -znocopyreloc has no effect on ARM. The result binary still contains an R_ARM_COPY relocation.

	$ cat data-ref.s
	.globl _start
		.p2align 4
	_start:
		bkpt

	.data
		.globl data_object
	object_reference:
		.long data_object
		.size object_reference,4

	$ cat libdata.s
		.data
		.globl data_object
		.type data_object, %object
		.size data_object, 4
	data_object:
		  .long 123

	$ as -o data-ref.o data-ref.s 
	$ as -o libdata.o libdata.s
	$ ld.bfd -shared -o libdata.so libdata.o
	$ ld.bfd -znocopyreloc -o data-ref data-ref.o libdata.so
	$ readelf -r data-ref

	Relocation section '.rel.dyn' at offset 0x20c contains 1 entries:
	 Offset     Info    Type            Sym.Value  Sym. Name
	000202c0  00000314 R_ARM_COPY        000202c0   data_object

Linking with ld.gold does the right thing:

	Relocation section '.rel.dyn' at offset 0x19c contains 1 entries:
	 Offset     Info    Type            Sym.Value  Sym. Name
	00009240  00000102 R_ARM_ABS32       00000000   data_object

Related to bug 16177 (I borrowed the example program from there).
Comment 1 Nick Clifton 2016-04-20 13:00:51 UTC 
Created attachment 9208 [details]
Proposed patch

Hi David,

  Please try out this patch.

Cheers
  Nick
Comment 2 Maxim Kuvyrkov 2019-01-03 13:02:05 UTC 
Hi David,

Any feedback on Nick's patch?
Comment 3 Richard Biener 2020-08-24 11:05:05 UTC 
It's reported that the same issue exists for aarch64 (and Nicks patch is meanwhile on master but only addresses arm).
Comment 4 Nick Clifton 2020-08-24 11:26:33 UTC 
Created attachment 12792 [details]
Proposed patch

FYI - here is a proposed, but completely untested, patch for the AArch64...
Comment 5 Michael Matz 2021-07-21 15:52:13 UTC 
So with current master binutils, without additional changes I don't see copy relocs on aarch64 with the (adjusted for data size) example:

% cat data-ref.s
.globl _start
        .p2align 4
_start:
        ret

.data
        .globl data_object
# .section        .rodata,"a",@progbits
object_reference:
        .quad data_object
        .size object_reference,8

% cat libdata.s
.data
        .globl data_object
        .type data_object, %object
        .size data_object, 8
data_object:
        .quad 123

% ./gas/as-new -o data-ref.o data-ref.s
% ./gas/as-new -o libdata.o libdata.s
% ./ld/ld-new -shared -o libdata.so libdata.o
% ./ld/ld-new -znocopyreloc -o data-ref data-ref.o libdata.so
% readelf -rW data-ref
Relocation section '.rela.dyn' at offset 0x230 contains 1 entry:
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
0000000000411000  0000000100000101 R_AARCH64_ABS64        0000000000000000 data_object + 0

This doesn't change when the '.section rodata' directive is uncommented, i.e.
when the reference comes from a read-only section.  Still no copy-reloc.

(Without the -znocopyreloc linker option we do generate a copy reloc, but
that's expected).

So, right now I don't see anything in need for fixing.  This all was somewhat
related to a go problem: https://github.com/golang/go/issues/22040 .  If that
one still exists then it's different from _this_ problem report here.

If there's new info or a reproducer that still shows a problem, please reopen.
Comment 6 Michael Matz 2021-07-21 16:01:40 UTC 
(And just FWIW: aarch64 binutils 2.36 and 2.37 don't have the problem either).