Relocating .data at 0x0

Relocating .data at 0x0

[David Robins]

I'm trying to write an ld script to have it relocate the .data segment at
0x0 (i.e., generate symbol addresses starting at 0x0 for all sections
included there).  My script looks like:

OUTPUT_FORMAT("a.out-i386-linux")
OUTPUT_ARCH("i386")
SECTIONS
{ 
  .text 0x20 :  
  { 
    CREATE_OBJECT_SYMBOLS
    *(.text)
    _etext = .;
    __etext = .;
  }
  .data 0x0 : AT(ADDR(.text)+SIZEOF(.text))
  { 
    *(.data)
    *(.rodata)   /* a.out has no separate rodata section */
    CONSTRUCTORS
  }
/* plus .bss and a /DISCARD/ pseudo-section */
}

This dies with:
/usr/local/bin/ld: final link failed: File truncated

It will die with 'Bad value' for 'File truncated' if I change the data
address to, say, 0x400.  The .text segment size is about 0xa000.

The purpose is to be able to set DS/ES/SS/FS/GS to the start of the data
segment directly, not the code segment, so that the first item in the
data segment will be DS:0, not DS:0xa000.

ld version 2.11.90.08, same BFD version, gcc is egcs-2.91.66.

Any help appreciated.

Dave
Isa. 40:31

Re: Relocating .data at 0x0

[Nick Clifton]

Hi David,

> I tracked down the problem to binutils/ld/aoutx.h ~line 1010:
> 
>   if (abdp && abdp->zmagic_mapped_contiguous)
>     { 
>       text_pad = (obj_datasec(abfd)->vma
>           - obj_textsec(abfd)->vma
>           - obj_textsec(abfd)->_raw_size);
>       obj_textsec(abfd)->_raw_size += text_pad;
>     }
>> 
> Since the VMA for .text was 0x30 and .data was at 0x0, text_pad is set
> negative and corrupts the .text output section's _raw_size, causing an
> error (the oh-so-descriptive "bad value") in the bfd_final_link stage.

Would you mind trying out the patch below, to see if it fixes the
problem ?

Cheers
        Nick

2001-06-12  Nick Clifton  <nickc@cambridge.redhat.com>

	* aoutx.h (adjust_z_magic): Do not pad the text section 
	if the data section is going to be placed before it.

Index: bfd/aoutx.h
===================================================================
RCS file: /cvs/src/src/bfd/aoutx.h,v
retrieving revision 1.19
diff -p -r1.19 aoutx.h
*** aoutx.h	2001/05/23 17:26:35	1.19
--- aoutx.h	2001/06/12 13:29:08
*************** adjust_z_magic (abfd, execp)
*** 1006,1015 ****
      }
    if (abdp && abdp->zmagic_mapped_contiguous)
      {
!       text_pad = (obj_datasec(abfd)->vma
! 		  - obj_textsec(abfd)->vma
! 		  - obj_textsec(abfd)->_raw_size);
!       obj_textsec(abfd)->_raw_size += text_pad;
      }
    obj_datasec(abfd)->filepos = (obj_textsec(abfd)->filepos
  				+ obj_textsec(abfd)->_raw_size);
--- 1006,1019 ----
      }
    if (abdp && abdp->zmagic_mapped_contiguous)
      {
!       asection * text = obj_textsec (abfd);
!       asection * data = obj_datasec (abfd);
! 
!       text_pad = data->vma - (text->vma + text->_raw_size);
!       /* Only pad the text section if the data
! 	 section is going to be placed after it.  */
!       if (text_pad > 0)
! 	text->_raw_size += text_pad;
      }
    obj_datasec(abfd)->filepos = (obj_textsec(abfd)->filepos
  				+ obj_textsec(abfd)->_raw_size);

Re: Relocating .data at 0x0

[David Robins]

Regarding the previous message that I posted:

I tracked down the problem to binutils/ld/aoutx.h ~line 1010:

  if (abdp && abdp->zmagic_mapped_contiguous)
    { 
      text_pad = (obj_datasec(abfd)->vma
          - obj_textsec(abfd)->vma
          - obj_textsec(abfd)->_raw_size);
      obj_textsec(abfd)->_raw_size += text_pad;
    }

In i386linux.c, MY_zmagic_contiguous is #defined to 1 which sets
zmagic_mapped_contiguous in the aout_backend_data struct.  Other targets
might not have the same problem.

Since the VMA for .text was 0x30 and .data was at 0x0, text_pad is set
negative and corrupts the .text output section's _raw_size, causing an
error (the oh-so-descriptive "bad value") in the bfd_final_link stage.

Granted, normally this problem won't occur, since most people don't need
that sort of linker script, but I just thought I'd mention it in case
perhaps someone wants to insert an assertion or check/warning, or if
someone has the same problem in the future they can read this.

Dave
Isa. 40:31