This is the mail archive of the cygwin-developers@sourceware.cygnus.com mailing list for the Cygwin 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


On Wed, May 12, 1999 at 06:07:52AM +0000, Mikey wrote:
>>>some   info   about   itself).   Will   this   program  be  gdb(jit),
>>>core-dumper(post-mortem), something else or nothing -- it's up to you.
>>
>>That sounds perfect to me.
>
>Not quite, this is code bloat, cygwin should pass unhandled exceptions
>to the kernel exception handler which could then be used to invoke
>gdb(JIT) or whichever debugger the developer chooses.

I get the feeling that you're not reading very carefully.  This is very
minimal "code bloat".  The only slowdown that I can see is when an
exception actually occurs.  At that point, an arbitrary program may be
run to handle it.

>Not everyone will want to use gdb as their only/cygwin debugger.

Are you just saying this to make a point or did you miss the "something
else or nothing -- it's up to you."?

>Win32 gdb should have a /dump command line option so that it could
>produce core files if the user wants them.  (based on the command line
>in aedebug)

This isn't a bad idea, except that a /dump option would be taken as
a file name, currently.

>This (aedebug) is a familiar interface for hundreds of thousands of
>win32 programmers, and shouldn't be replaced unless absolutely
>necessary, which it isn't, gdb itself will start and run just fine from
>the aedebug registry entry.  What it won't currently do is start the
>debug session correctly, it that were fixed all of this would be
>unnecessary.  (and you would be able to eliminate a lot of the code
>from exception.cc which would speed up cygwin:)

How would this speed up cygwin?  What code are you talking about?  Egor's?
Are you saying that you've actually looked at the code?

>Alternatively (as above) you could produce a stand alone dumper which
>would have the advantage of modularity, and speed.

Unless I'm missing something, that's exactly what he did!

>Trying to replace "kernel" functionality with a runtime is an exercise
>in balance, the more the runtime does the slower/larger it will be,
>whenever possible the runtime should be just a minimal interface
>between the published native api, and the unix/posix api, this goes way
>beyond that.
>
>Not that there aren't a lot of places in the dll that already do that
>;^)

And, of course, it's necessary to meet the stated goal of providing UNIX
functionality.  :-)

Let me summarize what has gone on, since you seem to have missed the
early discussion here.

Egor's initial goal was to make *cygwin* applications capable of running
a debuger.  He could have accomplished this goal by spending months
getting gdb to the point where it will substitute as a replacement for
Dr. Watson or MSVC.  DJ had already suggested that we could use the
same mechanism as those debuggers for handling exceptions.  I mentioned
that since gdb wasn't up to the level of being a general-purpose Windows
debugger this would cause problems for non-cygwin, non-mingw programs.

So, Egor implemented the perfectly reasonable approach of using the CYGWIN
environment variable to control how this was handled.  The amount
of code bloat is minimal.

I then suggested that true core dumps would be useful as long as the core
dump was handled by an external program.  And, guess what?  That's what
he's done.

It would be very nice to make gdb capable of doing all of the things that
windebug or MSVC can do.  If someone wants to submit patches to do this,
then I would be thrilled to accept them.  Until that point Egor's changes
are very much appreciated and will probably serve as a useful foundation
for things to come.

Also, FYI, I haven't incorporated any of Egor's changes into cygwin yet.
I'm still waiting for his assignment form to arrive.

cgf

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