Mail Archives: djgpp/2000/02/27/04:59:34
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 -