This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: new core files


The reason that win32 doesn't support core dumps
is that it supports JIT debugging.

Wouldn't it be more appropriate for this platform
to get gdb.exe to work correctly with JIT than
to clutter up everyones disks with a bunch of
core files that most people would have no
idea how to use, or why they are getting them?

For sure there needs to be an on/off setting in %CYGWIN%
that defaults to OFF.

I confess I took a hack at this myself (JIT), and couldn't
get anywhere, but the docs are there on the msdn.

It almost looks like you need to use 2 threads,
one to accept the initial debug events, 
(create process/thread load dll)
which then exits allowing the system to send out the
AED debug event and another (the main gdb thread) 
to attach to and actually control the app.

On Sat, 8 May 1999 16:06:27 -0400, you wrote:

>On Sat, May 08, 1999 at 07:48:21PM +0400, Egor Duda wrote:
>>I've written a (prototype) code to allow cygwin programs dump "real"
>>cores, and appropriate bfd back-end to make gdb understand them. And
>>i've got a couple of questions. First -- whether trapped program
>>should start separate process "a-la dr.Watson" to write core file, or
>>it should write core file by itself? And second -- where should *.core
>>go if current directory isn't writable?
>
>It should definitely be a separate process.  Otherwise we're bloating
>cygwin for the benefit of developers who want to look at core files.
>
>>Now, all committed pages from process's virtual memory are dumped to
>>core.  So dump of the minimal program takes 6-10M, depending of
>>presence or absence of debug info in cygwin1.dll.  I feel that it's a
>>bit overkill, but don't know common way to distinguish between "useful"
>>pages and "void" ones.
>
>I'm not sure why you're writing symbol information.  That shouldn't be
>necessary.  Symbol information should come from the DLL itself.  Also,
>there is no reason to write out the text segment since that should also
>be coming from the DLL also.
>
>I believe that the only thing that should show up in a core file is the
>stack, the heap, the data segments of the program and any DLLs (or at
>least the cygwin DLL) and register contents.
>
>>Yet another problem is with gdb itself.  I've made it support new
>>target "cygwin-core", but it still recognizes dump as coff :( Perhaps
>>that's because dump contains parts of exe's image, which look pretty
>>much like coff.  As a temporary workaround, I've set GNUTARGET env var
>>to "cygwin-core", but i don't feel it's a proper way.  So would anybody
>>kindly point me to the appropriate place in docs?
>
>This is probably a question for the gdb@sourceware.cygnus.com mailing list.
>Somebody there should be able to help you.
>
>I should point out that the subject of core dumps was recently raised in
>some gdb discusions.  There seems to be a general consensus that for
>targets, like cygwin, which don't support a native core dump format,
>that the target should use the ELF core dump format.  It seems to be the
>most flexible format for this type of thing.
>
>-chris


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]