Date: Sun, 27 Feb 2000 10:23:09 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Rossz Vámos-Wentworth cc: djgpp AT delorie DOT com Subject: Re: Cross compiler In-Reply-To: <38b77f2d_3@news.jps.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by delorie.com id DAA04707 Reply-To: djgpp AT delorie DOT com Errors-To: dj-admin AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Fri, 25 Feb 2000, Rossz Vámos-Wentworth wrote: > 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. It's hard to give an advice without the details. I guess you will have to dig a bit to find out why does it fail, and then tell the details here. > 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 Try this (as a single long line): objdump --disassemble --no-show-raw --start=0x2d691 --stop=0x2d695 \ h8300-hms-ld.exe The first instruction it shows is the one that crashed. Look at the instruction and find the register which holds the garbled value. Since GPF is caused by a bad pointer or bad offset into a structure, you need to compare the values of the potential offenders with the DS limit, printed above. > 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) What do the following commands print in GDB, after the program gets SIGSEGV? (gdb) print info (gdb) print info->vectors_sec (gdb) print info->vectors_sec->_raw_size > I don't really know how to use GDB Well, I'd suggest a nice long session with GDB and its manual. It is very hard to debug such problems without knowing at least some of GDB. > 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. See the docs of _crt0_startup_flags and specifically the _CRT0_FLAG_FILL_SBRK_MEMORY bit. If setting that bit makes the problem go away, your guess is correct.