From:	"Rossz Vámos-Wentworth" <rossw AT jps DOT net>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Cross compiler
Date:	Fri, 25 Feb 2000 23:19:14 -0800
Lines:	64
X-Priority:	3
X-MSMail-Priority:	Normal
X-Newsreader:	Microsoft Outlook Express 5.00.2615.200
X-MimeOLE:	Produced By Microsoft MimeOLE V5.00.2615.200
NNTP-Posting-Host:	209.239.194.140
X-Original-NNTP-Posting-Host:	209.239.194.140
Message-ID:	<38b77f2d_3@news.jps.net>
X-Trace:	25 Feb 2000 23:22:21 -0800, 209.239.194.140
X-Original-NNTP-Posting-Host:	209.63.224.240
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

I'm very close to getting a working set of tools and the cross compiler.
Only two problems remain, one minor with a work-around, and one serious.

The minor problem is the search path for ccp.  Unless I set GCC_EXEC_PREFIX
in the environment or makefile, GCC does not find CPP.  I can live with
this, but I wish I could get GCC to search for CPP from its relative
location without the override.

The serious problem is with LD.  Most of the time it experiences a SIGSEGV.
Sometimes it works.  The code it produces when it does work is perfectly
good (I downloaded it into the unit and it ran just fine).  Here's the
output of a build that I captured.  As you can see, LD worked twice, then
failed on the third item.  It usually doesn't work this often, just a lucky
run, I guess:

dump begins ----------------------------
h8300-hms-ld -T ../boot/legOS.lds -relax -Lf:/legOS/lib
helloworld.o  -lc -lmint -lfloat -o helloworld.ds1 -Ttext 0xb000
h8300-hms-ld -T ../boot/legOS.lds -relax -Lf:/legOS/lib
helloworld.o  -lc -lmint -lfloat -o helloworld.ds2 -Ttext 0xb210
f:/legOS/util/makelx helloworld.ds1 helloworld.ds2 helloworld.lx
h8300-hms-gcc -O2 -fno-builtin -fomit-frame-pointer -Wall -If:/legOS/include
 -I. -If:/legOS/boot -c rover.c -o rover.o
h8300-hms-ld -T ../boot/legOS.lds -relax -Lf:/legOS/lib
rover.o  -lc -lmint -lfloat -o rover.ds1 -Ttext 0xb000
Exiting due to signal SIGSEGV
General Protection Fault at eip=0002d691
eax=90ffffff ebx=0002d37c ecx=000548b0 edx=00000000 esi=00000054
edi=000eb8e8
ebp=000d6928 esp=000d6900 program=F:\DJGPP\CROSS\BIN\H8300~16.EXE
cs: sel=0157  base=83027000  limit=000effff
ds: sel=01bf  base=83027000  limit=000effff
es: sel=01bf  base=83027000  limit=000effff
fs: sel=0137  base=00012690  limit=0000ffff
gs: sel=01cf  base=00000000  limit=0010ffff
ss: sel=01bf  base=83027000  limit=000effff
App stack: [000d6a28..00056a28]  Exceptn stack: [0005697c..00054a3c]

Call frame traceback EIPs:
  0x0002d691
  0x000135d3
  0x00013d2f
  0x00016e11
  0x000197f1
  0x00040ea6
make.exe: *** [rover.ds1] Error -1
rm rover.ds1 helloworld.ds1 helloworld.ds2
dump ends ---------------------------------

I ran it under GDB and it said the problem is at line 1313 of
bfd/coff-h8300.c, here's the line of code:

    if (h8300_coff_hash_table (info)->vectors_sec->_raw_size != 0)

I don't really know how to use GDB, so I wasn't really able to get any
additional information.  Perhaps this problem is caused by an uninitialized
pointer.  I know some OSes initialize memory to all zeros when it is
allocated, but this is not the case with DOS.  Whatever happened to be lying
around in memory is what you get.

Rossz

- Raw text -