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

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
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
Updated/fixed patch (1.16 KB, patch)
2018-07-12 22:17 UTC, James Clarke
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
	_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
	$ ./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.

Cheers
  Nick
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.

Cheers
  Nick
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.

Thanks,

John
Comment 9 James Clarke 2018-07-12 22:17:06 UTC
Created attachment 11124 [details]
Updated/fixed patch

The original patch on this bug report looks at whether the symbol in question is in a read-only section, but that should have no effect on whether this symbol needs to be copied into the executable. Instead, it should be checking whether there are any relocations in read-only sections referring to the symbol, as that determines whether we are able to leave in dynamic relocations. Ben's rebased version also has the issue of messing with the SEC_READONLY check currently present; that should stay, as SEC_READONLY determines where the copied symbol should go, but only matters if we are doing a copy in the first place. This patch hasn't even been compile tested, but I'm 90% confident it works!