Re: Getting Closer

[Joel <joel_Schantz at yahoo dot com>]

Other "Thoughts"

Take a look at the Map file (it will tell you what and where things were loaded)

Examine the rm_rom.ld file. This sounds like it is(should be) doing all the work (correct start
files, libraries, etc)

When you get an error after you download you can use the Map and the $FN.cof file(with the help of
objdump) to examine the code that failed[you want to determine what code module generate the trap] .

Also use the CPU32Bug to poke around in memory to see the instruction that caused the error.
I don't know that debugger but it probably has a dissassembler.
 
on another note you shouldn't need so complicated a link command (assuming you built and installed
everything ok)

Just Playing around with the current cross here at home I use
gcc -b m68k-coff -V 2.95.2 hello.c -Wl,-T,test.ld -m68332

This does it all. (well no Map, srecs and and a.out)
 (note the -V 2.95.2 because my native Cygwin gcc is now 2.95.2-6 but my cross is 2.95.2)

If you don't feel so reckless the following works
m68k-coff-gcc -V 2.95.2 hello.c -Wl,-T,test.ld -m68332

When you look at your rm_rom.ld it may(should) have a STARTUP(rm_crt0.o)
and maybe different libs under GROUP but should look like bcc.ld
(read the documentation for ld)

---------	top of bcc.ld	--------------
STARTUP(crt0.o)
OUTPUT_ARCH(m68k)
/* Uncomment this if you want srecords. This is needed for a.out
 * if you plan to use GDB.
OUTPUT_FORMAT(srec)
 */
SEARCH_DIR(.)
GROUP(-lbcc -lc -lgcc)
----------------------------------------------

Hope this not too much a distraction.
Good Luck
--	joel


Mark Palmerino wrote:
> 
> Hi Kai,
> 
> Continuing from earlier, I am working on your suggestion to see if I can
> find what is different between the windows version and the unix version.
> 
> >From before, I worked out a sequence of commands that will successfully
> compile 'hello.c' on the unix system and produce an S-record file.
> 
> Here is the sequence:
> 
> -----------------------------------------------------------------
> #!/bin/sh
> 
> FN=hello
> 
> echo "Producing $FN.o..."
> m68k-coff-gcc -m68332 -c $FN.c
> 
> echo "Producing rm_crt0.o from rm_crt.S..."
> m68k-coff-gcc -m68332 -c rm_crt0.S
> 
> echo "Producing $FN.cof using ld..."
> m68k-coff-ld -o $FN.cof \
>   -L/usr/local/lib/gcc-lib/m68k-coff/2.8.1 \
>   -L/usr/local/m68k-coff/lib \
>    $FN.o -lc -lbcc -lgcc -T rm_rom.ld -M > $FN.map
> 
> echo "Producing S-record output..."
> m68k-coff-objcopy -O srec $FN.cof $FN.txt
> 
> tr -d '\r' < $FN.txt > $FN.s19
> cp $FN.s19 /hfs
> finderinfo -C MUMM -T TEXT /hfs/$FN.s19
> 
> echo "New output is in /hfs/$FN.s19"
> -----------------------------------------------------------------
> 
> I am not anywhere where I can download the S-record file to see if it works,
> but past experience leads me to believe it won't - but I will try it.
> 
> The next step I thought worth taking is to bring over the libc.a, libbcc.a
> and libgcc.a from the windows side and use them as arguments to the linker.
> I did that and put them in the directory that the hello.c file is in and
> here is the ld command which I used:
> 
> m68k-coff-ld -v -o $FN.cof \
>   -L. \
>    $FN.o -lc -lbcc -lgcc -T rm_rom.ld -M > $FN.map
> 
> Where $FN is 'hello'.  When I execute that command, I get:
> 
> ./libc.a(exit.o)(.text+0x52):exit.c: undefined reference to `_exit'
> ./libc.a(sbrkr.o)(.text+0x12):sbrkr.c: undefined reference to `sbrk'
> ./libc.a(makebuf.o)(.text+0xdc):makebuf.c: undefined reference to `isatty'
> ./libc.a(readr.o)(.text+0x1a):readr.c: undefined reference to `read'
> ./libc.a(lseekr.o)(.text+0x1a):lseekr.c: undefined reference to `lseek'
> ./libc.a(writer.o)(.text+0x1a):writer.c: undefined reference to `write'
> ./libc.a(closer.o)(.text+0x12):closer.c: undefined reference to `close'
> ./libc.a(fstatr.o)(.text+0x16):fstatr.c: undefined reference to `fstat'
> 
> This seems odd since all of these are declared in the libbcc.a library in
> the directory. Here is the output from ar:
> 
> m68k-coff-ar tv libbcc.a
> rw-rw-r-- 500/500   4440 Aug 13 22:23 1999 fstat.o
> rw-rw-r-- 500/500   2212 Aug 13 22:23 1999 getpid.o
> rw-rw-r-- 500/500   2234 Aug 13 22:23 1999 isatty.o
> rw-rw-r-- 500/500   2322 Aug 13 22:23 1999 kill.o
> rw-rw-r-- 500/500   2610 Aug 13 22:23 1999 putnum.o
> rw-rw-r-- 500/500   6510 Aug 13 22:23 1999 stat.o
> rw-rw-r-- 500/500   4318 Aug 13 22:23 1999 unlink.o
> rw-rw-r-- 500/500   5546 Aug 13 22:23 1999 lseek.o
> rw-rw-r-- 500/500   4484 Aug 13 22:23 1999 sbrk.o
> rw-rw-r-- 500/500   2232 Aug 13 22:23 1999 close.o
> rw-rw-r-- 500/500   4360 Aug 13 22:23 1999 open.o
> rw-rw-r-- 500/500   2396 Aug 13 22:23 1999 print.o
> rw-rw-r-- 500/500   2876 Aug 13 22:23 1999 read.o
> rw-rw-r-- 500/500   2532 Aug 13 22:23 1999 write.o
> rw-rw-r-- 500/500   1507 Aug 13 22:23 1999 cpu32bug.o
> 
> Changing the order of libbcc.a and libc.a does not seem to make a
> difference.
> 
> I don't quite know where to go from here. Do you have any suggestions?
> 
> In the meantime, I will check what libs the windows version is calling. As
> you suggest, this might give us a clue...
> 
> ------
> 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