m68k-rtems-gcc output file format

Charles-Antoine Gauthier charles.gauthier at nrc.ca
Mon Feb 28 14:13:15 UTC 2000

Joel Sherrill wrote:
> > "Kim, Jeong-Hwan" wrote:
> >
> > Hi, everyone
> > I am beginning with m68k-rtems-gcc compiler.
> > My target is M68K.
> > I wonder what format does m68k-rtems-gcc compiler support for output
> > file.
> > Does it produce executable file in S-Record format or Intel Hex
> > format?
> By default the output of as/gcc/ld is coff or elf depending on
> which version of the tools and patches you have.  The 4.0 era
> used coff.  Recently most of the tool targets changed to elf.
> The output produced by the linking process is often converted
> to another object format so it can be downloaded to a target board.
> Many of the m68k BSPs use objcopy to produce Srecords -- especially
> the mvme* ones.
> The file named ".exe" for all BSPs is appropriate for download
> to the target -- whatever that format is.

Almost true :-). Our MVME167 and MBX8xx ports do not produce Motorola
S-records. We download the stripped executables using the onboard ROM
debugger (167Bug or EPPCBug) using the NIOP command on the MVME167 and
the PLH command on the MBX8xx. When we use the NIOP command, we offset
by the number of bytes in the file header, so that the debugger actually
starts loading the .text section at the start address we selected in
RAM. The PLH command is smarter: it reads the ELF header and relocates
the .text, .data and .bss sections to their designated addresses.

Now, if a user wanted to download through the serial line, or if the
onboard ROM debugger was replaced, he or she would have to produce the
S-records or some other appropriate format.

> > And I have a another problem.
> > When I wrote a very simple code and compiled with m68k-rtems-gcc
> > and checked with  bfd library, bfd_check_format() with bfd_object
> > type,
> > the function returned error.
> > What reason do you think it happened ...?
> Why are you in the bowels of the bfd library?  Surely you invoked
> some binutils tool and are reporting a debugger path.
> If on UNIX, use "file XXX" to figure this out.  m68k-rtems-objdump
> is also useful.  If it is an Srecords file, you can always just look
> at it with an editor and confirm it.
> More than likely the file you are looking at is m68k-coff.
> > Kim
> >
> >
> >
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel at OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985

Charles-Antoine Gauthier
Research Officer
Software Engineering Group
Institute for Information Technology
National Research Council of Canada
Ottawa, ON, Canada
K1A 0R6

More information about the users mailing list