Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
From: Chris Faylor <cgf AT cygnus DOT com>
Date: Fri, 21 Apr 2000 10:48:52 -0400
To: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: PS1, gdb and other trubbels
Message-ID: <20000421104852.A7931@cygnus.com>
Reply-To: cygwin AT sourceware DOT cygnus DOT com
Mail-Followup-To: cgf AT cygnus DOT com, cygwin AT sourceware DOT cygnus DOT com
References: <200004201759 DOT TAA02478 AT sauerkraut-und-lederhosen DOT e DOT kth DOT se> <20000420144815 DOT A1549 AT cygnus DOT com> <am3dogh7cg DOT fsf AT sauerkraut-und-lederhosen DOT e DOT kth DOT se> <20000420162205 DOT B2308 AT cygnus DOT com> <amu2gwfr3x DOT fsf AT sauerkraut-und-lederhosen DOT e DOT kth DOT se> <20000420174130 DOT B3346 AT cygnus DOT com> <amd7nj9972 DOT fsf AT sauerkraut-und-lederhosen DOT e DOT kth DOT se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.8i
In-Reply-To: <amd7nj9972.fsf@sauerkraut-und-lederhosen.e.kth.se>; from lha@stacken.kth.se on Fri, Apr 21, 2000 at 09:58:41AM +0200

On Fri, Apr 21, 2000 at 09:58:41AM +0200, Love wrote:
>Chris Faylor <cgf AT cygnus DOT com> writes:
>> On Thu, Apr 20, 2000 at 10:35:14PM +0200, Love wrote:
>> >Chris Faylor <cgf AT cygnus DOT com> writes:
>> >
>> >> >I can give you a tarboll with binaries that cause the error.
>> >> 
>> >> Sorry.  I definitely don't have time to debug individual problems.
>> >
>> >Sure, I'll happly try to find it out myself, I currenly trying to build a
>> >libcygwin1.dll with debugging symbols.
>> 
>> You should be able to set breakpoints in gdb to find out where the
>> problem is occurring.  The fact that cygwin shows up on a stack trace
>> does not mean that the problem is in cygwin.  Cygwin intercepts all of
>> the Windows "signals" in order to properly emulate UNIX signals.
>
>Ok, so you mean that Visual C just tells me where the exception should be
>handled but wasn't ? It looked on the assembely that it really did the
>*(int *)0x4 = N; in cygwin1.dll. But then I'm not that good on i386
>assembly.

Let's use an analogy.  If you notice that you get a SIGSEGV in strcpy,
do you immediately think something is wrong with strcpy or do you assume
that you've passed something incorrect to strcpy?

It's certainly possible that there is something wrong with cygwin but before
you grab all of the sources and attempt to rebuild everything it makes sense
to me to attempt to narrow down exactly where the problem is occurring.

The old "It works on linux (hp-ux, dgux, digital unix, irix)!" cry,
while popular, does not mean that your code is bug-free.  Rather than waste
days talking about this and trying to build cygwin, I'm suggesting that
you use standard debugging techniques to find out if there is an error in
your program.

>> If I were you, I would just debug your program in the normal way before
>> going to the effort of building cygwin.
>
>Well I build it, no problem there. Are you using /cygdrive/c/cygwin as
>prefix when building the release ?

No.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com