Mail Archives: djgpp/1998/03/02/08:15:22
From: | "Andris Pavenis" <pavenis AT acad DOT latnet DOT lv>
|
Newsgroups: | comp.os.msdos.djgpp
|
Subject: | Some problems with RHIDE and GDB
|
Date: | Mon, 02 Mar 1998 06:58:17 -0600
|
Organization: | Deja News - The Leader in Internet Discussion
|
Lines: | 64
|
Message-ID: | <6deacf$8l5$1@nnrp1.dejanews.com>
|
NNTP-Posting-Host: | postnews.dejanews.com
|
To: | djgpp AT delorie DOT com
|
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp
|
Hi!
I'm using already for some time for DJGPP (and also under Linux)
modified version of RHIDE 1.4.1. I have sent patches to Robert Hoehne.
There were still some other problems:
- there is some problems when compiling GDB under DJGPP (All is OK
under Linux):
compiled version of gdb.exe does not process correctly SIGINT.
Call stack after SIGINT is corrupted so it is impossible to
continue execution of program after that. I have applied patch
to dbgcom.c and also other patches supplied with sources of
RHIDE-1.4. I tried to build gdb.exe both with gcc-2.7.2.1 and
gcc-2.8.0 and both versions did'nt react correctly on SIGINT.
If I see that compiled version of gdb has such problem it is likely
to expect it also in libgdb.a used by RHIDE. Currently available
versions of RHIDE (including 1.4.3) simply terminates program
after SIGINT. Under Linux I modified procedure
'annotate_signal_string_end ()' (file librhgdb/gdbinter.c) to
avoid killing of process I'm debugging. After that it worked.
I only havent yet added enforcing showing disassembler window
in this situation so there is problems if this feature is used
without enabling showing disassembler window when necessary.
I didn't tried this under DJGPP due to the problems with compilation
of gdb.exe
- one of the problem discussed recently in DJGPP mailing list was
crashing of user compiled version of RHIDE in MS-DOS when no DPMI
server is available and CWSDPMI is being used. Unfortunatelly one
my recent message didn't go to this mailing list due to network
problems. Therefore I'm only shortly pointing on the source of
this problem:
the problem was due to call to bindtextdomain() (file bindtextdom.c)
from libintl.a before libintl.a is initialized (see procedures
with __attribute__((contructor)) in getdirs.c). One possible
workaround for this problem is to modify libintl.a to ensure
the initialization of library even if bindtextdomain() is called
too early. The result of this problem is
strcmp (something,NULL) where something is some string.
Win95 DPMI server does not complain about such operation, but
with CWSDPMI it causes segmentation fault.
I havent tried to look if similar problem is with Linux version
(I think it maybe there).
- Looks that there is problem with building nested project when some of
project items (project one library) is located on a different drive
than the main project. In this situation both compilation of some
sources from project and linking exe file works OK when requested
explicitly (^F9 and Compile->Link). Building EXE fails due to unresolved
references so there is no EXE file built. Trying to make procect
(Compile -> Make or Compile -> BuildAll) does nothing even if there is
no object files. Removing the project for that library from main project
fixes the problem. After putting it back make works only first time when
dependencies for library is checked. Perhaps this may be the same problem
when after trying to add some source (that is already in some library)
RHIDE fails to find that EXE file should be rebuilt.
Andris Pavenis
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
- Raw text -