Re: Core dumps

[Christopher Faylor <cgf at cygnus dot com>]

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 <cgf@cygnus.com> 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@sourceware.cygnus.com.  You can
subscribe via binutils-subscribe@sourceware.cygnus.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