From: "Rossz Vámos-Wentworth" 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