Bug 16177 - R_ARM_COPY reloc generated for reference in writable section
Summary: R_ARM_COPY reloc generated for reference in writable section
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.25
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2013-11-15 20:51 UTC by Roland McGrath
Modified: 2018-01-12 23:03 UTC (History)
4 users (show)

See Also:
Last reconfirmed:

Proposed patch (525 bytes, patch)
2016-04-20 13:00 UTC, Nick Clifton
Details | Diff
Rebased patch (667 bytes, patch)
2018-01-10 02:55 UTC, John Ericson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Roland McGrath 2013-11-15 20:51:34 UTC
When a writable input section (i.e. data) refers to a symbol defined in an
ET_DYN object, BFD ld for ARM targets generates a COPY dynamic reloc.  For
other targets like x86, this situation generates a plain data dynamic
reloc.  Gold for ARM also generates the plain data dynamic reloc.

I can't understand any rationale for generating a synthetic data object and
copy reloc for it in this situation.  A copy reloc is only appropriate when
the reference is from a read-only input section (e.g. from an instruction).

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

		.globl data_object
		.long data_object
		.size object_reference,4
	$ cat libdata.s
		.globl data_object
		.type data_object, %object
		.size data_object, 4
		  .long 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 -o data-ref data-ref.o libdata.so
	$ readelf -r data-ref

	Relocation section '.rel.dyn' at offset 0x224 contains 1 entries:
	 Offset     Info    Type            Sym.Value  Sym. Name
	100302bc  00000314 R_ARM_COPY        100302bc   data_object
	$ ./gold/ld-new -o data-ref-gold data-ref.o libdata.so
	$ readelf -r data-ref-gold

	Relocation section '.rel.dyn' at offset 0x190 contains 1 entries:
	 Offset     Info    Type            Sym.Value  Sym. Name
	00009230  00000102 R_ARM_ABS32       00000000   data_object
Comment 1 Ben Gamari 2014-01-20 18:19:58 UTC
This appears to be responsible for brokenness on ARM when the Glasgow Haskell Compiler is used to produce dynamically linked executables https://ghc.haskell.org/trac/ghc/ticket/4210#comment:29.
Comment 2 Nick Clifton 2016-04-20 13:00:19 UTC
Created attachment 9207 [details]
Proposed patch

Hi Ben,

  Please try this patch.

Comment 3 Nick Clifton 2016-04-20 13:01:45 UTC
Ben or Roland that is...
Comment 4 Ben Gamari 2017-04-07 00:23:53 UTC
Unfortunately my ARM hardware bit the dust. I'm waiting to take shipment of a new board and will test when it arrives.
Comment 5 Ben Gamari 2017-07-01 22:57:34 UTC
My new hardware arrived. Naturally the patch required a bit of rebasing. My guess can be found here, https://github.com/bgamari/binutils-gdb/commit/539f59256dd8b503b1188eecb30a338ee38616f8. I've started a GHC build linking with the linker from this commit. I'll let you know when it's finished and I've verified that it works.
Comment 6 John Ericson 2018-01-10 02:55:57 UTC
Created attachment 10727 [details]
Rebased patch

This is Ben Gamari's rebase of the original patch, included here for posterity.
Comment 7 Nick Clifton 2018-01-10 09:17:14 UTC
The question is - does the patch work ?

I am happy to apply it, provided that it can be confirmed that it works
in a real ARM-based system.

Comment 8 John Ericson 2018-01-12 23:03:40 UTC
I just copied it, but think I'll be able to confirm that for you by end of next week.