This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


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

RE: m68k assembler (and MRI tools)


>I believe it's "Microtec Research Inc".
>
>Ben

It is, in fact, Microtec Research Inc. The "I" is probably
a leftover from before they were acquired by Mentor Graphics
Corp, in 1995 or 1996. Mentor Graphics now refers to the compilers
as the "Microtec C and C++ Compilers".

I believe Mentor got MRI's compilers, XRAY debugger, and VRTX
RTOS (which MRI got from Ready Systems a couple years earlier).

All of which brings me to MY question:
Has anybody moved from the MRI tools to GCC for the 68K? While
using a 3rd-party library (object code only)?  I've been using
the MRI tools for the last couple of years to develop code for
a box that runs VRTX. The manufacturer of the box has an SDK
that includes libraries. The libraries were created with the
MRI tools. I MUST link with these libraries (or some derivative)
because the entry points into VRTX are contained within it.
The manufacturer's code in the box is statically linked with
VRTX, and I need to make calls to both VRTX and hardware
support routines in the manufacturer's code.

I've built GCC 2.95.3 (m68k-elf) and can compile/assemble/
link CPU32 code, with S-Record output. No problems there -
as long as I don't reference this SDK library.

I guess my problem/question is now: has anybody taken MRI
libraries and converted them to a format usable by the GCC
toolchain? My planned scheme is:
 1. Extract modules from library using MRI librarian, resulting
    in module.obj
 2. Use m68k-elf-objcopy to move module.obj to module.o
 3. Use m68k-elf-objcopy to rename sections from MRI convention
    to GCC convention
 4. Use m68k-elf-ar to "rebuild" the library
I've played with it a little bit, and step 2 results in an
IEEE-format object file. I'll probably convert to elf32-m68k
in step 2.

After disassembling such a converted object file and looking
at relocation records, everything *looks* OK. A sample object
module looks like:

$ ./m68k-elf-objdump.exe -h module.o

module.o:     file format elf32-m68k

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 0             00000000  00000000  00000000  00000034  2**1
                  ALLOC
  1 code          00000170  00000000  00000000  00000034  2**1
                  CONTENTS, ALLOC, LOAD, RELOC, CODE
  2 .debug        00001fc2  00000000  00000000  000001a4  2**0
                  CONTENTS, DEBUGGING

I don't need the .debug section. Any idea what the '0' section
might be? 

Just wondering if anybody's taken this route before, and if they
might have any tips.

-Don


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


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