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
Precedence: bulk

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