>From: CBFalconer [EMAIL PROTECTED]
>Date: Thu, 31 Oct 2002 11:20:45 -0500
>To: [EMAIL PROTECTED]
>Subject: Re: gdb hangs on a 486
>
>
>"Larry Hall (RFK Partners, Inc)" wrote:
>>
>> At 11:13 PM 10/30/2002, CBFalconer wrote:
>> >I have been trying out gdb in Cygwin, and found it to hang and/or
>> >crash under W98, running on a 486. The output of gdb --version
>> >is:
>> >
>>... snip ...
>> > > This GDB was configured as "i686-pc-cygwin".
>> > ^^^^^^^^^^^^^^
>> >This appears unwarranted. I would have assumed gdb would test and
>> >adapt itself to the processor on which it is running.
>>
>> At this point, I think most (all?) Cygwin packages are configured
>> like this. Whether or not that's true, it's not unwarranted. There's
>> good reason to make use of the newer architectures' capabilities.
>
>I can easily believe that. It seems very poor practice to make
>these assumptions without checking them somewhere and generating a
>warning. Such things can go in initialization or loading code.
Sure. I doubt many programs actually do architecture checks as part
of their startup though. If you're arguing that this should be the
case, I won't contest it. In a perfect world, this would probably
be the case. It's a low enough pain-threshold for the majority that
the lack of this check is not noticed. But that's a separate issue
from your point.
>... snip ...
>>
>> gdb -nw
>>
>
>Are you saying that the problem is limited to the GUI interface?
>Is this known, or just a guess?
Actually, no I'm not saying that. However, you mentioned that gdb
came up in the GUI version, which I read as preference not to have the
GUI. That's really all I was pointing out. It's possible that the
command line version would cause less windowing/mouse problems though.
I don't expect that the command line version targets i486 while the GUI
targets something later however.
>>
>> Sounds like you may want to get the source, reconfigure, and build
>> your own version targeting i386 or i486.
>
>A non-trivial job, especially if the very tools are suspect.
A potentially non-trivial job, yes, depending on your skills and
experience building packages. I'm not sure what you're referring to
by "the very tools are suspect". These tools have been around for a
long time. They worked when these architectures were the default
configuration. It shouldn't be too hard to get them working on
those targets now. If you're referring to the fact that the tools
don't check if the run-time environment matches the configuration
environment on start-up, I think labeling the tools as "suspect" for
this oversight is a little extreme. But I may be missing your meaning.
Larry
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
