Bug 11542 - ld -r generates R_X86_64_NONE
Summary: ld -r generates R_X86_64_NONE
Status: NEW
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.20
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-26 20:26 UTC by Mark Wielaard
Modified: 2011-05-12 22:24 UTC (History)
3 users (show)

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


Attachments
part-1 (126 bytes, text/plain)
2011-05-11 10:50 UTC, Christian Bruel
Details
part-2 (103 bytes, text/plain)
2011-05-11 10:52 UTC, Christian Bruel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Wielaard 2010-04-26 20:26:07 UTC
This comes up when building a kernel module debuginfo. A .rela.debug_info
section contains R_X86_64_NONE relocations. It is for a symbol in a section
called .discard, which the linker script discards. It seems that ld -r should
eat the reloc rather than leave *_NONE.

Reproducer based on kernel module build:

$ cat > foo.c
int here, there __attribute__ ((section (".discard")));

$ cat > module-common.lds
/*
 * Common module linker script, always used when linking a module.
 * Archs are free to supply their own linker scripts.  ld will
 * combine them automatically.
 */
SECTIONS {
        /DISCARD/ : { *(.discard) }
}

$ ld -r -o foo2.o module-common.lds foo.o ld: warning: module-common.lds
contains output sections; did you forget -T?

$ ld -r -o foo2.o -T module-common.lds foo.o
$ readelf -r foo2.o

Relocation section '.rela.debug_info' at offset 0x618 contains 11 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000006  00040000000a R_X86_64_32       0000000000000000 .debug_abbrev + 0
00000000000c  00080000000a R_X86_64_32       0000000000000000 .debug_str + b
000000000011  00080000000a R_X86_64_32       0000000000000000 .debug_str + 38
000000000015  00080000000a R_X86_64_32       0000000000000000 .debug_str + 6
000000000019  000100000001 R_X86_64_64       0000000000000000 .text + 0
000000000021  000100000001 R_X86_64_64       0000000000000000 .text + 0
000000000029  00060000000a R_X86_64_32       0000000000000000 .debug_line + 0
00000000002e  00080000000a R_X86_64_32       0000000000000000 .debug_str + 33
00000000003b  000c00000001 R_X86_64_64       0000000000000004 here + 0
00000000004b  00080000000a R_X86_64_32       0000000000000000 .debug_str + 0
000000000058  000000000000 R_X86_64_NONE                        0000000000000000

Relocation section '.rela.debug_pubnames' at offset 0x720 contains 1 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000006  00050000000a R_X86_64_32       0000000000000000 .debug_info + 0
Comment 1 H.J. Lu 2010-04-27 18:07:42 UTC
It may be too late for linker to remove a relocation in
elf_link_input_bfd since it will change section header
and file layout.
Comment 2 cvs-commit@gcc.gnu.org 2010-04-30 18:27:56 UTC
Subject: Bug 11542

CVSROOT:	/cvs/src
Module name:	src
Changes by:	hjl@sourceware.org	2010-04-30 18:27:33

Modified files:
	bfd            : ChangeLog elf-bfd.h elf32-i386.c elf64-x86-64.c 
	ld/testsuite   : ChangeLog 
Added files:
	ld/testsuite/ld-elf: discard.ld discard1.d discard1.s discard2.d 
	                     discard2.s discard3.d 

Log message:
	Remove relocation against discarded sections for relocatable link.
	
	bfd/
	
	2010-04-30  H.J. Lu  <hongjiu.lu@intel.com>
	
	PR ld/11542
	* elf-bfd.h (RELOC_AGAINST_DISCARDED_SECTION): New.
	
	* elf32-i386.c (elf_i386_relocate_section): Use it.
	* elf64-x86-64.c (elf64_x86_64_relocate_section): Likewise.
	
	ld/testsuite/
	
	2010-04-30  H.J. Lu  <hongjiu.lu@intel.com>
	
	PR ld/11542
	* ld-elf/discard.ld: New.
	* ld-elf/discard1.d: Likewise.
	* ld-elf/discard1.s: Likewise.
	* ld-elf/discard2.d: Likewise.
	* ld-elf/discard2.s: Likewise.
	* ld-elf/discard3.d: Likewise.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&r1=1.5005&r2=1.5006
http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf-bfd.h.diff?cvsroot=src&r1=1.303&r2=1.304
http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf32-i386.c.diff?cvsroot=src&r1=1.232&r2=1.233
http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf64-x86-64.c.diff?cvsroot=src&r1=1.194&r2=1.195
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ChangeLog.diff?cvsroot=src&r1=1.1247&r2=1.1248
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-elf/discard.ld.diff?cvsroot=src&r1=NONE&r2=1.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-elf/discard1.d.diff?cvsroot=src&r1=NONE&r2=1.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-elf/discard1.s.diff?cvsroot=src&r1=NONE&r2=1.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-elf/discard2.d.diff?cvsroot=src&r1=NONE&r2=1.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-elf/discard2.s.diff?cvsroot=src&r1=NONE&r2=1.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-elf/discard3.d.diff?cvsroot=src&r1=NONE&r2=1.1

Comment 3 H.J. Lu 2010-04-30 18:34:05 UTC
Fixed for i386 and x86-64.
Comment 4 Christian Bruel 2011-05-11 10:50:54 UTC
Created attachment 5715 [details]
part-1
Comment 5 Christian Bruel 2011-05-11 10:52:35 UTC
Created attachment 5716 [details]
part-2

Reproduce with:

g++ -fasynchronous-unwind-tables -fno-rtti -fno-exceptions -c -o foo.o foo.i
g++ -fasynchronous-unwind-tables -fno-rtti -fno-exceptions -c -o bar.o bar.i

ld   -r -o foor.o foo.o bar.o

objdump -r foor.o | grep NONE
0000000000000098 R_X86_64_NONE     *ABS*
Comment 6 Christian Bruel 2011-05-11 10:58:20 UTC
A new reduced case showing R_*_NONE relocation in .eh_frame for a relocatable module. 
Might not be a bug (R_*NONE should be allowed in the final ELF, but since this has not been covered by the patch in #2, I wonder if there is a solution to cleanup this one as well.
Comment 7 H.J. Lu 2011-05-12 22:24:53 UTC
(In reply to comment #6)
> A new reduced case showing R_*_NONE relocation in .eh_frame for a relocatable
> module. 
> Might not be a bug (R_*NONE should be allowed in the final ELF, but since this
> has not been covered by the patch in #2, I wonder if there is a solution to
> cleanup this one as well.

It is done on purpose:

http://sourceware.org/ml/binutils/2010-04/msg00479.html