RE: M68k a.out grief

RE: M68k a.out grief

[Holland, Alexander MHX]

Unfortunately when I investigated your reasonable suggestion, I found that
m68k-coff-objcopy.exe does not support a translation to a.out. I have also
had bad luck with this approach in the past. All of the ICE's that I have
used have been very sensitive to the exact tool chain, configuration, and
steps used to generate an output format with debug symbols. I tried objcopy
COFF to IEEE695, for example, and it did not come close to the ICE vendor's
requirements.

Thanks,
Alex

-----Original Message-----
From: Art Berggreen [ mailto:art@acc.com ]
Sent: Thursday, December 21, 2000 12:00 PM
To: Holland, Alexander MHX
Cc: 'crossgcc@sources.redhat.com'
Subject: Re: M68k a.out grief


"Holland, Alexander MHX" 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. 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. Does anyone have
any
> a.out linker script examples or techniques that provide more flexible
output
> section control?

If I recall correctly, a.out format ONLY support the three basic
sections (text, data and bss).  You might look into linking under coff
and using objcopy to covert to an a.out load module.  I've never looked
into how objcopy maps sections.

Art

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to
crossgcc-unsubscribe@sourceware.cygnus.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

Re: M68k a.out grief

[Bill Randle]

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

Re: M68k a.out grief

[Michael Sokolov]

"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.

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

--
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)

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

Re: M68k a.out grief

[Art Berggreen]

"Holland, Alexander MHX" 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. 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. Does anyone have any
> a.out linker script examples or techniques that provide more flexible output
> section control?

If I recall correctly, a.out format ONLY support the three basic
sections (text, data and bss).  You might look into linking under coff
and using objcopy to covert to an a.out load module.  I've never looked
into how objcopy maps sections.

Art

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

M68k a.out grief

[Holland, Alexander MHX]

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. 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. Does anyone have any
a.out linker script examples or techniques that provide more flexible output
section control? 

Thanks!
Alex

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