Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com Date: Sun, 9 Jan 2000 21:46:42 -0500 From: Christopher Faylor To: Egor Duda Cc: cygwin-developers Subject: Re: Core dumps Message-ID: <20000109214642.A31545@cygnus.com> Mail-Followup-To: Egor Duda , cygwin-developers References: <19991229161240 DOT E7370 AT cygnus DOT com> <7706 DOT 000104 AT logos-m DOT ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <7706.000104@logos-m.ru>; from deo@logos-m.ru on Tue, Jan 04, 2000 at 04:57:34PM +0300 Hi, I've finally had time to look at these patches. There are a few comments below. On Tue, Jan 04, 2000 at 04:57:34PM +0300, Egor Duda wrote: >Dec 30 1999 Christopher Faylor wrote: >CF> It is likely that this won't apply cleanly against gdb, at least, but >CF> we'll let you know. > >I've looked at gdb and bfd snapshots from 1999-12-21, and remake all >patches. Seems that new StackWalk scheme won't work with core files >(at least i don't know if it is possible to use SymInitialize() & Co. This should still be possible with StackWalk, I believe. I have an example somewhere that actually produces a crude core file and uses StackWalk to manipulate it. However, I'm less enamored with StackWalk than I had been when I changed gdb. I thought that StackWalk would be able to do the right thing with some (apparently) frameless system routines in kernel32 but AFAICT, this is not the case. StackWalk may eventually allow us to understand Microsoft symbol information, though, so I'll probably leave it in. >APIs without having running process, so i left old way of stack >tracing if we debug core dump. I've also changed winsup patch to >provide synchronization between core dumper and trapped process, and >to prevent recursive "error_start"ing of processes -- debugger can >possibly trap, and if so, we'll effectively get machine down with >a lots of spawning processes. > >Patch to bfd includes configure.in changes, so 'configure' script >should be regenerated. Would you mind submitting the bfd and top-level include patches to the binutils mailing list? It's at binutils AT sourceware DOT cygnus DOT com. You can subscribe via binutils-subscribe AT sourceware DOT cygnus DOT com. >I've also encountered a small problem with gdb-19991221 -- it handles >global cygwin1.dll variables like 'myself' or 'tty_master' >incorrectly (_without my patches too_). I'll try to research this >problem if i have time. I have noticed this too. Does your recent patch fix this? cgf