PS1, gdb and other trubbels

PS1, gdb and other trubbels

[Love]

I have some problems, i'm using the 1.1.0 release on w2k.

Since I have w2k, I have problems with gdb. A previous noted I can
attach to processes just fine. I really want gdb so I started by
download the gdb src tarball in the latest/gdb directory, but there
was no instruction in there how to build it. Where do I start to be
able to find it ?

Does gdb handle windows threads ? It seams to recognize them, but
there is not backtrace and it gets really confused where function
frame start/end.

Have anyone considered finishing pthread_cond\* functions so the
pthread interface might be complete or are you waiting for someone to
send them in :) ?

A minor nit, there is no release notice on the website.

Love

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: PS1, gdb and other trubbels

[Chris Faylor]

On Thu, Apr 20, 2000 at 07:59:18PM +0200, Love wrote:
>Does gdb handle windows threads ? It seams to recognize them, but
>there is not backtrace and it gets really confused where function
>frame start/end.

gdb does support threads.  Did you try any of the thread commands?
You are probably confused by the fact that the program may not be
stopped on the main thread when you attach to it.  Try issuing the
"thread 1" command before requesting a backtrace.

As I indicated in the earlier thread which mentioned W2K problems,
I am not exactly sure what is causing this problem.  However, I've
taken an educated guess and made some changes to gdb.  I've put
a modified version of gdb here:

ftp://ftp.cygnus.com/private/home/cgf/gdb.exe.bz2

If someone wants to try this out and let the cygwin list know how it
works that would be great.

>I really want gdb so I started by download the gdb src tarball in the
>latest/gdb directory, but there was no instruction in there how to
>build it.  Where do I start to be able to find it ?

I'm sorry, but you have a long road ahead of you if you are asking this
question.  cygwin is just like any other GNU utility.  You need to
download the source for what you're building and any additional packages
that it requires.  So, downloading just the gdb source tarball is not
enough.  You'll have to (off the top of my head) download, binutils and
common as well.

Then you do a "configure" in the toplevel directory followed by a "make
all-gdb".  This is all exactly the same as building any other GNU utility.
Possibly there are more instructions on the GNU web site but I don't
know for sure.

>Have anyone considered finishing pthread_cond\* functions so the
>pthread interface might be complete or are you waiting for someone to
>send them in :) ?

As always, patches are gratefully accepted.

>A minor nit, there is no release notice on the website.

Huh? There "New Cygwin Net Release" item on the web site.  DJ put it there
before the announcement went out.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: PS1, gdb and other trubbels

[Love]

Chris Faylor <cgf@cygnus.com> writes:

> On Thu, Apr 20, 2000 at 07:59:18PM +0200, Love wrote:
> >Does gdb handle windows threads ? It seams to recognize them, but
> >there is not backtrace and it gets really confused where function
> >frame start/end.
> 
> gdb does support threads.  Did you try any of the thread commands?
> You are probably confused by the fact that the program may not be
> stopped on the main thread when you attach to it.  Try issuing the
> "thread 1" command before requesting a backtrace.
        
I did that info threads && thread N dance but that didn't work.
 
> ftp://ftp.cygnus.com/private/home/cgf/gdb.exe.bz2
> 
> If someone wants to try this out and let the cygwin list know how it
> works that would be great.

Yeah, it works. Thanks.
 
> >I really want gdb so I started by download the gdb src tarball in the
> >latest/gdb directory, but there was no instruction in there how to
> >build it.  Where do I start to be able to find it ?
> 
> I'm sorry, but you have a long road ahead of you if you are asking this
> question.

Ok, I'm just confused what is the layout the the lastest/* tree, but I
think I understand it now. I'm was just consfused that there wasn't a
configure in the top dir in lastest/gdb/gdb-20000415.tar.gz tar-ball.

> >A minor nit, there is no release notice on the website.
> 
> Huh? There "New Cygwin Net Release" item on the web site.  DJ put it there
> before the announcement went out.

I mean the mail that DJ send to the mailing list.

I have another problem too. I have a program that crashes under cygwin
(works for many other) and I suspenct that the error is in cygwin1.dll
since that is what the debugger in VC claims the error is. Its refences 0x4
an get a "Application Error". gdb is just confused and can't do the
intresting stacktrace (see below). How do I make sure the error is in my
program and not cygwin1.dll ?

I can give you a tarboll with binaries that cause the error.

Love


Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 608.0x460]
0x6104b0d8 in _size_of_stack_reserve__ ()
(gdb) bt
#0  0x6104b0d8 in _size_of_stack_reserve__ ()
Cannot access memory at address 0x2000000

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: PS1, gdb and other trubbels

[Chris Faylor]

On Thu, Apr 20, 2000 at 09:59:11PM +0200, Love wrote:
>I have another problem too. I have a program that crashes under cygwin
>(works for many other) and I suspenct that the error is in cygwin1.dll
>since that is what the debugger in VC claims the error is. Its refences 0x4
>an get a "Application Error". gdb is just confused and can't do the
>intresting stacktrace (see below). How do I make sure the error is in my
>program and not cygwin1.dll ?
>
>I can give you a tarboll with binaries that cause the error.

Sorry.  I definitely don't have time to debug individual problems.

Is the stack trace below the result of running the gdb that I just
made available or some other version?  It looks like an older version of
gdb which had this particular problem with stack traces.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: PS1, gdb and other trubbels

[Love]

Chris Faylor <cgf@cygnus.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.
 
> Is the stack trace below the result of running the gdb that I just
> made available or some other version?  It looks like an older version of
> gdb which had this particular problem with stack traces.

It was the gdb that you gave me that had support for w2k.

Love  

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: PS1, gdb and other trubbels

[Chris Faylor]

On Thu, Apr 20, 2000 at 10:35:14PM +0200, Love wrote:
>Chris Faylor <cgf@cygnus.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.

If I were you, I would just debug your program in the normal way before
going to the effort of building cygwin.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: PS1, gdb and other trubbels

[Love]

Chris Faylor <cgf@cygnus.com> writes:

> On Thu, Apr 20, 2000 at 10:35:14PM +0200, Love wrote:
> >Chris Faylor <cgf@cygnus.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.
 
Thanks for the tips.

> 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 ?

Love

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: PS1, gdb and other trubbels

[Love]

Love <lha@stacken.kth.se> writes:

> > 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.
> 
> Thanks for the tips.

But you're right, there is some weirdo stuff going on in my
lwp-on-pthread-on-windows-threads emulation package that I wrote
previously. It works with our old thread package that does the stack
switching itself. Guess I'll have to fix pthreads in cygwin some way...

Thanks for the new gdb, works great.

Love

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: PS1, gdb and other trubbels

[Chris Faylor]

On Fri, Apr 21, 2000 at 09:58:41AM +0200, Love wrote:
>Chris Faylor <cgf@cygnus.com> writes:
>> On Thu, Apr 20, 2000 at 10:35:14PM +0200, Love wrote:
>> >Chris Faylor <cgf@cygnus.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@sourceware.cygnus.com

Re: PS1, gdb and other trubbels

[Love]

Chris Faylor <cgf@cygnus.com> writes:

> 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?
 
Point taken.

> >Well I build it, no problem there. Are you using /cygdrive/c/cygwin as
> >prefix when building the release ?
> 
> No.

You are instead using ?

Love

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: PS1, gdb and other trubbels

[Chris Faylor]

On Sat, Apr 22, 2000 at 05:24:55PM +0200, Love wrote:
>Chris Faylor <cgf@cygnus.com> writes:
>>>Well I build it, no problem there.  Are you using /cygdrive/c/cygwin as
>>>prefix when building the release ?
>>
>>No.
>
>You are instead using ?

I assume that DJ is probably using --prefix=/usr but I don't know for sure
and it really doesn't matter.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: PS1, gdb and other troubles

[DJ Delorie]

> I assume that DJ is probably using --prefix=/usr but I don't know
> for sure and it really doesn't matter.

I am using --prefix=/usr

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: PS1, gdb and other trubbels

[Trevor Forbes]

>
> > ftp://ftp.cygnus.com/private/home/cgf/gdb.exe.bz2
> >
> > If someone wants to try this out and let the cygwin list know how it
> > works that would be great.
>
> Yeah, it works. Thanks.

It works a lot better but I sometimes get the following warning window when
I load the program I am debugging or when the program being debugged exits:

"Program received signal SIGTRAP, Trace/breakpoint trap"

and if I step the asm instruction in gdb which is the only button which
seems to help.  I get the following in the gdb console window

61000000:F:/Cygwin/bin/cygwin1.dll
error return /cygnus/src/sourceware/gdb/win32-nat.c:1189 was 6

Program received signal SIGSEGV, Segmentation fault.
0x77f86839 in ?? ()




Trevor

Config - Win2K, Fat32, Cyg 1.1, snapshot 20000421


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com