This is the mail archive of the crossgcc@cygnus.com mailing list for the crossgcc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
On Wed, 13 Jan 1999, Wynn Rostek wrote: > Does anyone have experience with the GNU tool chain supporting the Coldfire > processor? We've got assemblers but the job would go quicker with a C > compiler and a debugger. > the gnu binutils (2.9.1 I think, grab the newest) support coldfire (target=m68k-coff) -> so you have as, ld, objdump, nm, ar, objcopy... Disassembler (objdump) has some difficulties with some coldfire instructions (e.g. halt) but is quite usable. the gcc 2.8.1. has coldfire support - but is buggy in that respect (in rare cases produces instructions that the assembler rejects - illegal for coldfire) the egcs-1.1.1 compiler is better, produces code that actually works use both as and gcc with -m5200 debugging: I have written a bdm debugger plus linux kernel module for remote bdm debugging. this supports low level (asm debugging) operations like stepping and breakpoint (one hardware breakpoint plus one address or data breakpoint), up/download, flash programming, mem dump and editing. Requires no software on the target, works even with a coldfire with power and clock and nothing else. This is needed to get a new hardware development up and running and to debug crt0 stuff. Furthermore I have written a gdb extended remote stub (via tcp network) to have m68k-coff-gdb 4.17 (slightly patched) talk to the bdm target. Connects to the target with gdb> target extened-remote hostname.domain:port gdb> load object-file gdb> symbol-file object-file gdb> break main gdb> continue The remote stub which talks bdm with target is started from inetd, so you can choose host and port. The machine needs on unused parallel port for the bdm adapter (can provide schematics and GAL equation - or you can buy one from P&E Microsystems for US$99 I think). I debug software on a target that is in the other office, so I don't have to see the chaos I create. There is no need for any software on the target, but breakpoints may only be set in RAM (gdb patches coldfire halt instructions at breakpoints, original gdb uses a trap instruction). I am currently using it and it works ok, should be considered beta. I will activate my private web page at my ISP soon, then you can get all the debugging related files from there. the patch for gdb 4.17 is simple: in a header file change the REMOTE_BREAKPOINT from the trap instruction to coldfire's halt. I will provide a diff for that file. > TIA, any info appreciated. I hope this helps. Rolf +-----------------+--------------------------------------------------+ | _____ | Rolf Fiedler | | / ___/ | Electronic Design Engineer | | / _/ | Ferrari electronic AG | | /_/e/r/r/a/r/i/ | phone: +49 3328 4559 0 fax: +49 3328 4559 60 | | electronic | E-Mail: Rolf.Fiedler@Ferrari.DE | +-----------------+--------------------------------------------------+ "Where do you want to go tomorrow?" _______________________________________________ New CrossGCC FAQ: http://www.objsw.com/CrossGCC _______________________________________________ To remove yourself from the crossgcc list, send mail to crossgcc-request@cygnus.com with the text 'unsubscribe' (without the quotes) in the body of the message.