Re: M68k a.out grief

["Bill Randle" <billr@exgate.tek.com>]

On Dec 21,  6:51pm, Michael Sokolov wrote:
} Subject: Re: M68k a.out grief
} "Holland, Alexander         MHX" <HollaA@HPD.Abbott.com> wrote:
}
} > In order to use a particular in-circuit emulator, I switched  from a GNU
} > 2.95.2 m68k-coff target format to a GNU 2.95.2 m68k-aout format.
}
} Why would you do that? Your hardware can't possibly care or even know how you
} use your GNU toolchain.

Oh yes it can! He's talking about an in-circuit emulator - presumably used
in conjunction with a source level debugger. You need to download the
object code in a particular format to the emulator or it would understand
what you're sending it.

} > However, I
} > am running into problems creating a linker script that provides even a
} > minimum level of output section control. For example, my COFF script
creates
} > a ".vectors" section, specifies that the data part of my vectors module (a
} > vector table data struct) go into this section, and locates the section at
} > the base of ROM. The a.out linker seems not to allow me to specify any
} > section different from the standard .text, .data, .bss.
}
} But this is the whole point of a.out and COFF! a.out .text, .data, and .bss
} (and nothing else) by definition. COFF allows you to create your own sections
} and that's what it was invented for in the first place.
}
} > Does anyone have any
} > a.out linker script examples or techniques that provide more flexible
output
} > section control?
}
} This is impossible by definition.

Well, I wouldn't state it quite so strongly. While it's true you can't
have sections other than .text, .data and .bss, you can locate sections
of code into different places *on a file or symbol basis* which should be
sufficient for what he's trying to do.

For instance, here's a linker script file we use (m68k-a.out):

OUTPUT_FORMAT("a.out-sunos-big")
OUTPUT_ARCH(m68k)
SECTIONS
{
  .text (TEXT) :
  {
    CREATE_OBJECT_SYMBOLS
    *(.text)
    _etext = ALIGN(4);
  }
  .data :
  {
    _sdata  = .;
    *(.data)
        CONSTRUCTORS
    _edata  =  ALIGN(4);
  }
  .bss :
  {
   _sbss = .;
   *(.bss)
   _nvram = .;
   . = . + 2;
   process/o/nvdata.o (COMMON)
   _nvram_crc = .;
   . = . + 2;
   *(COMMON)
   _end = ALIGN(4);
  }
}

While this doesn't locate the vector table at the start of ROM, it does
do some special things with the .bss section, like define the location
of some global symbols and force the COMMON section of the nvdata.o file
to be located after the .bss section and before all the other COMMON
sections.

So, you should be able to do something like this:
	.text (TEXT) :
	{
	  CREATE_OBJECT_SYMBOLS
	  vectors.o (.data)
	  *(.text)
	  _etext = ALIGN(4);
	}
	etc.

to force the location of the data section of the vector table into the start
of ROM.

	-Bill Randle
	Tektronix, Inc.
	billr@exgate.tek.com


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com