This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gold script handling of program headers


Upon trying to linux a sparc64 Linux kernel we get:

/home/davem/src/GIT/constsection-2.6/gcc/ld: internal error in do_write, at ../../src/gold/output.cc:351

because this->offset() is non-zero for a file header, it's 0x3f50.

The simplest test case is:

-------------------- test.lds --------------------
OUTPUT_FORMAT("elf64-sparc", "elf64-sparc", "elf64-sparc")
OUTPUT_ARCH(sparc:v9a)
ENTRY(_start)
SECTIONS
{
 .text 0x0000000000404000 : { *(.text) }
}
-------------------- test.lds --------------------

-------------------- test.s --------------------
	.text
	.globl	_start
_start:	nop
-------------------- test.s --------------------

gcc -m64 -c -o test.o test.s
gold -T test.lds -o test test.o

How in the world does the offset of the file header get set like this?
It seems to be coming from the following special hack found in
Script_sections::create_segments():

  // An ELF program should work even if the program headers are not in
  // a PT_LOAD segment.  However, it appears that the Linux kernel
 ...

  if ((first_seg->paddr() & (abi_pagesize - 1)) >= sizeof_headers)
    {
      first_seg->set_addresses(first_seg->vaddr() - sizeof_headers,
			       first_seg->paddr() - sizeof_headers);
      return first_seg;
    }

first_seg->vaddr() == 0x404000
sizeof_headers == 0xb0

So the resulting offset is 0x403f50, and this is where the bogus
non-zero this->offset() seen by Output_file_header::do_write() seems
to come from.

For whatever reason I couldn't compose a similar test case that would
trigger on elf32-i386, but I admit that I didn't try all that hard :-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]