www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/02/27/04:59:34

Date: Sun, 27 Feb 2000 10:23:09 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Rossz Vámos-Wentworth <rossw AT jps DOT net>
cc: djgpp AT delorie DOT com
Subject: Re: Cross compiler
In-Reply-To: <38b77f2d_3@news.jps.net>
Message-ID: <Pine.SUN.3.91.1000227102241.14604W-100000@is>
MIME-Version: 1.0
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

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.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019