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