Cygwin 1.1.0 gdb troubles

Cygwin 1.1.0 gdb troubles

[Boyd Adamson]

Hi, I just installed cygwin 1.1.0. and I was looking forward to playing with
Insight, but had a problem with gdb hanging when I run even the simplest
program under it.

bash-2.03$ cat trial.c
#include <stdio.h>

int main(int argc, char **argv){
    printf("This is a test\n");
    exit(0);
}
bash-2.03$ gcc -Wall -g3 -o trial trial.c
bash-2.03$ ls -l
total 8
-rw-r--r--   1 boyd     Administ      100 Apr 18 14:23 trial.c
-rwxr-xr-x   1 boyd     Administ    13179 Apr 18 14:24 trial.exe
bash-2.03$ ./trial
This is a test
bash-2.03$ gdb -nw trial.exe
GNU gdb 20000204
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) run
Starting program: /tmp/trial.exe
61000000:d:/cygwin/bin/cygwin1.dll
77db0000:D:/WINNT/system32/ADVAPI32.DLL
77e80000:D:/WINNT/system32/KERNEL32.DLL
77d30000:D:/WINNT/system32/RPCRT4.DLL

... and there it hangs. This happens in the gui as well.

Anyway, in the process of trying to work this out I used a find command and
got
this output (The redirection only hides the output from directories other
than
/tmp & /usr)

bash-2.03$ find / > /dev/null
find: /tmp: No such file or directory
find: /uninst.bat: No such file or directory
find: /usr: No such file or directory
bash-2.03$ ls -l /
total 66
drwxr-xr-x   2 boyd     Administ    28672 Apr 18 14:17 bin
drwxr-xr-x   3 boyd     Administ     4096 Apr 18 14:17 lib
drwxr-xr-x   2 boyd     Administ        0 Apr 18 14:17 tmp
-rwxr-xr-x   1 boyd     Administ    96927 Apr 18 14:17 uninst.bat
drwxr-xr-x  12 boyd     Administ     4096 Apr 18 14:17 usr
bash-2.03$ mount
Device              Directory           Type         Flags
d:\cygwin\bin       /usr/bin            user         binmode
d:\cygwin\lib       /usr/lib            user         binmode
d:\cygwin           /                   user         binmode

Are these issues related? Could it be that the problem find is
having with the /tmp directory is causing gdb's woes?

I'm on Win2000 with an NTFS filesystem if it makes any difference.

Thanks for any help in advance,

Boyd


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

Re: Cygwin 1.1.0 gdb troubles

[Chris Faylor]

On Tue, Apr 18, 2000 at 02:32:46PM +1000, Boyd Adamson wrote:
>Hi, I just installed cygwin 1.1.0. and I was looking forward to playing with
>Insight, but had a problem with gdb hanging when I run even the simplest
>program under it.
>[snip]
>I'm on Win2000 with an NTFS filesystem if it makes any difference.

Other people have reported that gdb hangs on W2K.  I don't know why,
unfortunately.

cgf

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

Re: Cygwin 1.1.0 gdb troubles

[Chris Faylor]

On Tue, Apr 18, 2000 at 12:47:19AM -0400, Chris Faylor wrote:
>On Tue, Apr 18, 2000 at 02:32:46PM +1000, Boyd Adamson wrote:
>>Hi, I just installed cygwin 1.1.0. and I was looking forward to playing with
>>Insight, but had a problem with gdb hanging when I run even the simplest
>>program under it.
>>[snip]
>>I'm on Win2000 with an NTFS filesystem if it makes any difference.
>
>Other people have reported that gdb hangs on W2K.  I don't know why,
>unfortunately.

Out of curiousity, are you able attach to a running process with this
version of insight?  Looking at gdb's code, it's possible that this will
go through a slightly different code path that may not hang.

cgf

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

RE: Cygwin 1.1.0 gdb troubles

[Boyd Adamson]

> On Tue, Apr 18, 2000 at 12:47:19AM -0400, Chris Faylor wrote:
> >On Tue, Apr 18, 2000 at 02:32:46PM +1000, Boyd Adamson wrote:
> >>Hi, I just installed cygwin 1.1.0. and I was looking forward to
> playing with
> >>Insight, but had a problem with gdb hanging when I run even the simplest
> >>program under it.
> >>[snip]
> >>I'm on Win2000 with an NTFS filesystem if it makes any difference.
> >
> >Other people have reported that gdb hangs on W2K.  I don't know why,
> >unfortunately.
>
> Out of curiousity, are you able attach to a running process with this
> version of insight?  Looking at gdb's code, it's possible that this will
> go through a slightly different code path that may not hang.

Actually, yes, I am able to attach to a running process, although I have to
use the process ID that the Windows Task Manager gives, not the pid that
bash gives for a background job. I saw this particular behavior in B20 also.

Boyd


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

Re: Cygwin 1.1.0 gdb troubles

[Chris Faylor]

On Tue, Apr 18, 2000 at 04:45:45PM +1000, Boyd Adamson wrote:
>> On Tue, Apr 18, 2000 at 12:47:19AM -0400, Chris Faylor wrote:
>> >On Tue, Apr 18, 2000 at 02:32:46PM +1000, Boyd Adamson wrote:
>> >>Hi, I just installed cygwin 1.1.0. and I was looking forward to
>> playing with
>> >>Insight, but had a problem with gdb hanging when I run even the simplest
>> >>program under it.
>> >>[snip]
>> >>I'm on Win2000 with an NTFS filesystem if it makes any difference.
>> >
>> >Other people have reported that gdb hangs on W2K.  I don't know why,
>> >unfortunately.
>>
>> Out of curiousity, are you able attach to a running process with this
>> version of insight?  Looking at gdb's code, it's possible that this will
>> go through a slightly different code path that may not hang.
>
>Actually, yes, I am able to attach to a running process, although I have to
>use the process ID that the Windows Task Manager gives, not the pid that
>bash gives for a background job. I saw this particular behavior in B20 also.

I.e., it's working as designed.  gdb works on more than just cygwin processes.

cgf

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

Re: Cygwin 1.1.0 gdb troubles

[Tim Prince]

gdb appears to run normally here; I'm using W2KRC2 NTFS, cygwin 19990819
snapshot, gcc-2.96 and gcc-2.95.2 built without any of the special
adaptations for cygwin

----- Original Message -----
From: "Chris Faylor" <cgf@cygnus.com>
> Other people have reported that gdb hangs on W2K.  I don't know why,
> unfortunately.
>
> cgf



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

Re: Cygwin 1.1.0 gdb troubles

[Chris Faylor]

On Tue, Apr 18, 2000 at 06:12:44AM -0700, Tim Prince wrote:
>gdb appears to run normally here; I'm using W2KRC2 NTFS, cygwin 19990819
>snapshot, gcc-2.96 and gcc-2.95.2 built without any of the special
>adaptations for cygwin

How about the net release, though?  That's what the original post was all
about.

cgf

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

RE: Cygwin 1.1.0 gdb troubles

[Heribert Dahms]

Hi Chris,

but how can I get then the proper Unix behavior
for a program foo writing it's getpid() to foo.id:
gdb foo `cat foo.id`
without manually looking up WINPID?

Bye, Heribert (heribert_dahms@icon-gmbh.de)

> -----Original Message-----
> From:	Chris Faylor [SMTP:cgf@cygnus.com]
> Sent:	Tuesday, April 18, 2000 21:29
> To:	cygwin@sourceware.cygnus.com
> Subject:	Re: Cygwin 1.1.0 gdb troubles
> 
> On Tue, Apr 18, 2000 at 04:45:45PM +1000, Boyd Adamson wrote:
> [Heribert]  [snip]
> >Actually, yes, I am able to attach to a running process, although I
> have to
> >use the process ID that the Windows Task Manager gives, not the pid
> that
> >bash gives for a background job. I saw this particular behavior in
> B20 also.
> 
> I.e., it's working as designed.  gdb works on more than just cygwin
> processes.
> 
> cgf
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

Re: Cygwin 1.1.0 gdb troubles

[Chris Faylor]

On Tue, Apr 18, 2000 at 11:08:35PM +0200, Heribert Dahms wrote:
>but how can I get then the proper Unix behavior for a program foo
>writing it's getpid() to foo.id: gdb foo `cat foo.id` without manually
>looking up WINPID?

If you're talking about translating the cygwin pid to a windows pid,
you can get both using the "ps -l" command.

cgf

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

RE: Cygwin 1.1.0 gdb troubles

[Heribert Dahms]

Hi Chris,

sure, that's why I said without manual lookup!

Bye, Heribert (heribert_dahms@icon-gmbh.de)

> -----Original Message-----
> From:	Chris Faylor [SMTP:cgf@cygnus.com]
> Sent:	Tuesday, April 18, 2000 23:26
> To:	'cygwin@sourceware.cygnus.com'
> Subject:	Re: Cygwin 1.1.0 gdb troubles
> 
> On Tue, Apr 18, 2000 at 11:08:35PM +0200, Heribert Dahms wrote:
> >but how can I get then the proper Unix behavior for a program foo
> >writing it's getpid() to foo.id: gdb foo `cat foo.id` without
> manually
> >looking up WINPID?
> 
> If you're talking about translating the cygwin pid to a windows pid,
> you can get both using the "ps -l" command.
> 
> cgf
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

Re: Cygwin 1.1.0 gdb troubles

[Chris Faylor]

On Tue, Apr 18, 2000 at 11:30:17PM +0200, Heribert Dahms wrote:
>sure, that's why I said without manual lookup!

I wasn't suggesting that you manually lookup the pid.  It
is easy to parse the ps output in a shell script.

cgf

>> On Tue, Apr 18, 2000 at 11:08:35PM +0200, Heribert Dahms wrote:
>> >but how can I get then the proper Unix behavior for a program foo
>> >writing it's getpid() to foo.id: gdb foo `cat foo.id` without
>> manually
>> >looking up WINPID?
>> 
>> If you're talking about translating the cygwin pid to a windows pid,
>> you can get both using the "ps -l" command.

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

RE: Cygwin 1.1.0 gdb troubles

[Heribert Dahms]

Hi Chris,

it's easy, but is there a guarantee that the format dosen't change?
I remember man ps from HP-UX 10.20 under WARNINGS:

      Users of ps must not rely on the exact field widths and spacing of
its
      output, as these will vary depending on the system, the release of
      HP-UX, and the data to be displayed.

Bye, Heribert (heribert_dahms@icon-gmbh.de)

> -----Original Message-----
> From:	Chris Faylor [SMTP:cgf@cygnus.com]
> Sent:	Tuesday, April 18, 2000 23:38
> To:	'cygwin@sourceware.cygnus.com'
> Subject:	Re: Cygwin 1.1.0 gdb troubles
> 
> On Tue, Apr 18, 2000 at 11:30:17PM +0200, Heribert Dahms wrote:
> >sure, that's why I said without manual lookup!
> 
> I wasn't suggesting that you manually lookup the pid.  It
> is easy to parse the ps output in a shell script.
> 
> cgf
> [Heribert]  [snip] 

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

RE: Cygwin 1.1.0 gdb troubles

[Christopher Jones]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

Title: RE: Cygwin 1.1.0 gdb troubles







> -----Original Message-----
> From: Heribert Dahms [ mailto:heribert_dahms@icon-gmbh.de ]
> Sent: Tuesday, April 18, 2000 6:02 PM
> To: 'cygwin@sourceware.cygnus.com'
> Subject: RE: Cygwin 1.1.0 gdb troubles
> 
> 
> Hi Chris,
> 
> it's easy, but is there a guarantee that the format dosen't change?
> I remember man ps from HP-UX 10.20 under WARNINGS:
> 
>       Users of ps must not rely on the exact field widths and 
> spacing of
> its
>       output, as these will vary depending on the system, the 
> release of
>       HP-UX, and the data to be displayed.
> 


Seems like it would make more sense to at least hide these cygwin pids and let users always use windows pids for ps, kill, $$ in a shell, etc.  So the PID and PPID values would be the real windows values and cygwin pids would disappear into the internals somewhere... probably a lookup table if you really need to have them still.  Something like this would be more seemless, wouldn't it?

Brian

Re[2]: Cygwin 1.1.0 gdb troubles

[Paul Sokolovsky]

Hello Christopher,

Christopher Jones <cbjones@nortelnetworks.com> wrote:

CJ> Seems like it would make more sense to at least hide these cygwin pids and
CJ> let users always use windows pids for ps, kill, $$ in a shell, etc.  So the
CJ> PID and PPID values would be the real windows values and cygwin pids would
CJ> disappear into the internals somewhere... probably a lookup table if you
CJ> really need to have them still.  Something like this would be more seemless,
CJ> wouldn't it?

    If no cygwin people will agree with you, then at least me will.
IMHO, win32 is undoubtfully POSIX by spirit, only having somewhat
twisted upbringing. Almost any POSIX feature maps one-to-one to win32
one and difference is only in some idiosyncratic details. As an
example, DeleteFile() does exactly what remove() does with one
difference: remove() explicitly states possibility of removing opened
file, while DeleteFile() explicitly prohibits it. I can't believe
there's some adequate reasoning behind DeleteFile()'s behaviour. I
just can imagine some win32 architect reading POSIX spec and time to
time exclaiming: 'And *here*, we'll do vice-versa!' ;-)

     Well, what idiosyncratic features of native pids would harden
their usage as POSIX pisd as-is?

1. While NT's pids are rather POSIX-correct as-is, 9x's ones are
negative values, large (up to 10 dec digits) by module.
2. There's no documented way to get ppid on NT.
3. It's impossible to overlay image of current process. This means,
when performing usual fork-exec chain, there will be three processes:
parent, exec() implementer stub and execed child. So, between child
and parent in POSIX terms there will be other process.

    While these problems may seem denying original idea, they hardly
do. The workarounds for them exist, working and confidently may be
called more robust than maintaining additional superstructures,
moreover shared between all processes.

    Well, *that*'s not most annoying feature of cygwin. Just net
version ago there might arise problems with just having cygwin work
properly after installation, mostly because ungrounded default mount
table setup. But look - this version now takes care to ask user where
he wants having root mount. So, all consistently improving and maybe
one day other areas also will be addressed.


CJ> Brian




--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135



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

Re: Cygwin 1.1.0 gdb troubles

[DJ Delorie]

> Almost any POSIX feature maps one-to-one to win32 one and difference
> is only in some idiosyncratic details.

This is an understatement.  For every feature that maps one-to-one, it
seems like there are a dozen idiosyncratic details that make it
difficult to meet the POSIX requirements.  A large portion of Cygwin
is devoted to these details.

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

Re[2]: Cygwin 1.1.0 gdb troubles

[Paul Sokolovsky]

Hello DJ,

DJ Delorie <dj@delorie.com> wrote:


>> Almost any POSIX feature maps one-to-one to win32 one and difference
>> is only in some idiosyncratic details.

DD> This is an understatement.  For every feature that maps one-to-one, it
DD> seems like there are a dozen idiosyncratic details that make it
DD> difficult to meet the POSIX requirements.  A large portion of Cygwin
DD> is devoted to these details.

    Well, we won't argue on precise number of details and level of
difficulty to work them around.

     Instead, I'll take chance to thank for installation changes in
new release. Don't know why it happened, but changes exactly how I
personally like to see it: per-application packaging and attentive
setup asking user for important things, such as root mount. I just
wonder whether it could be installed without running that setup at all
;-) Also, it's interesting how cygwin.dll behaves when run on new
computer: previous used to install default mount entry with root
mounted on window's drive. Of course, that's ungrounded and give
problems to any folks who prefer keep ms' oses and rest of soft on
different drives ;-) . Bad luck I have my inet connection broken and
have to sit and twaddle instead of take a look myself ;-(


--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135



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

Re: Cygwin 1.1.0 gdb troubles

[DJ Delorie]

> I just wonder whether it could be installed without running that
> setup at all

Yup.  Just download all the .tar.gz files you want, and bootstrap.zip.
Unzipping bootstrap.zip gives you temporary copies of the few files
you need to unpack the tar.gz files.  Then use mount to setup your
mount table, and write your own cygwin.bat shortcut.

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

Re: Cygwin 1.1.0 gdb troubles

[Chris Faylor]

On Wed, Apr 19, 2000 at 10:13:02PM +0300, Paul Sokolovsky wrote:
>>> Almost any POSIX feature maps one-to-one to win32 one and difference
>>> is only in some idiosyncratic details.
>
>DD> This is an understatement.  For every feature that maps one-to-one, it
>DD> seems like there are a dozen idiosyncratic details that make it
>DD> difficult to meet the POSIX requirements.  A large portion of Cygwin
>DD> is devoted to these details.
>
>    Well, we won't argue on precise number of details and level of
>difficulty to work them around.

Nope.  We'll just make vague assertions that cygwin could do it much
better and that will be that.

cgf

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

Re: Cygwin 1.1.0 gdb troubles

[Chris Faylor]

On Wed, Apr 19, 2000 at 04:53:38PM +0300, Paul Sokolovsky wrote:
>    If no cygwin people will agree with you, then at least me will.
>IMHO, win32 is undoubtfully POSIX by spirit, only having somewhat
>twisted upbringing. Almost any POSIX feature maps one-to-one to win32
>one and difference is only in some idiosyncratic details. As an
>example, DeleteFile() does exactly what remove() does with one
>difference: remove() explicitly states possibility of removing opened
>file, while DeleteFile() explicitly prohibits it. I can't believe
>there's some adequate reasoning behind DeleteFile()'s behaviour. I
>just can imagine some win32 architect reading POSIX spec and time to
>time exclaiming: 'And *here*, we'll do vice-versa!' ;-)

So, how do you work around this tiny little flaw then?  How does your
magic wand work?

>     Well, what idiosyncratic features of native pids would harden
>their usage as POSIX pisd as-is?
>
>1. While NT's pids are rather POSIX-correct as-is, 9x's ones are
>negative values, large (up to 10 dec digits) by module.
>2. There's no documented way to get ppid on NT.
>3. It's impossible to overlay image of current process. This means,
>when performing usual fork-exec chain, there will be three processes:
>parent, exec() implementer stub and execed child. So, between child
>and parent in POSIX terms there will be other process.
>
>    While these problems may seem denying original idea, they hardly
>do. The workarounds for them exist, working and confidently may be
>called more robust than maintaining additional superstructures,
>moreover shared between all processes.

I'd like to hear your workaround for these problems.  Really.  I'm eager
to incorporate your advanced thinking into cygwin's design.  Or are you
just here to poke fun and jeer?

>Well, *that*'s not most annoying feature of cygwin.  Just net version
>ago there might arise problems with just having cygwin work properly
>after installation, mostly because ungrounded default mount table
>setup.  But look - this version now takes care to ask user where he
>wants having root mount.  So, all consistently improving and maybe one
>day other areas also will be addressed.

Probably the most annoying feature of cygwin for me is that people seem
to be compelled to criticize it while offering only vague generalities
and smug assertions that they could do it better.

It is astounding to me that this is an open source project for which
patches have always been accepted but people like you find it acceptable
to criticize the way things are done.  If you don't like the way cygwin
handles things, feel free to redesign and improve.  As I stated, I would
be quite fascinated to see patches which illustrate your ideas.

Before you offer the standard response of "I'm too busy", just take a
moment to reflect on what that statement means.  If you are too busy to
actually investigate these "problems" and offer concrete solutions, then
why should I believe that your ideas have any merit whatsoever?  How can
you adequately criticize something that you don't understand?

Ah.  The next argument will be that you have already implemented your
own POSIX-on-Windows and know everything that Cygwin did wrong.  So,
ok.  I'm willing to listen to how you mapped UNIX signals onto what
Win32 offers.  I'll be interested in hearing how you got exec() working.
You probably have implemented a fork.  I'd be interested in hearing how
it differs substantially from what cygwin offers.  Hmm.  You disparage
the cygwin mount table.  Let's hear how you have tackled this problem.

I don't consider any of this off-topic for this mailing list.  I envision
that you will probably want to enlighten us all with a series of articles
on how it could all be done better, complete with actual code samples.

Since this will be a substantial work, I guarantee that I will set aside
a portion of my day, every day to read and analyze what you post.  In fact,
I'm quite looking forward to your submissions.  Although you're probably
too busy to provide cygwin patches, I expect that your insightful articles
will still provide substantial fodder for future cygwin development.

cgf

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

Re[2]: Cygwin 1.1.0 gdb troubles

[Paul Sokolovsky]

Hello Chris,

Chris Faylor <cgf@cygnus.com> wrote:

>>difference: remove() explicitly states possibility of removing opened
>>file, while DeleteFile() explicitly prohibits it. I can't believe

CF> So, how do you work around this tiny little flaw then?  How does your
CF> magic wand work?

    Bad metaphor, it's for sure not magic, just pure technology, and
hardly can be considered sufficiently advanced. So, currently I just
ignore such error condition. So, after typical configure session with
bash tens of orphaned files lie in /tmp. That sucks. I already made
support for close-on-exec, but instead of set of flags I used array of
fds which need to closed. So, one sweet day I will re-make it as
arrays of flags, add new should-be-deleted on close flag to it. Then,
close() will check that flag and delete that file. Well, but how I
will get filename to delete? I know of no way to get it by handle, and
I'm not going to store filename for each opened file.

    This illustrates whole picture of my writing another Posix layer
from scratch: maybe I really will do better with 20% percents of
functionality, but with rest 80% I will just go thru the lot of burden
to come to things long before done in cygwin. And for some fraction of
those 80% my stuff will remain inferior to cygwin forever.

>>     Well, what idiosyncratic features of native pids would harden
>>their usage as POSIX pisd as-is?
>>
>>1. While NT's pids are rather POSIX-correct as-is, 9x's ones are
>>negative values, large (up to 10 dec digits) by module.
>>2. There's no documented way to get ppid on NT.
>>3. It's impossible to overlay image of current process. This means,
>>when performing usual fork-exec chain, there will be three processes:
>>parent, exec() implementer stub and execed child. So, between child
>>and parent in POSIX terms there will be other process.

CF> I'd like to hear your workaround for these problems.  Really.  I'm eager
CF> to incorporate your advanced thinking into cygwin's design.  Or are you
CF> just here to poke fun and jeer?

    Nope, I'm here to communicate on questions interesting to me, one
of them is how to have best Posix layer for win32. Best here means not
only by technical properties, but also by reputation, support,
community size, etc., etc. No need to say that cygwin is closest to
this position and I hope will remain so. And since I'm hacker (or
wannabe, YMMV) I take non-technical merits for granted, being grateful
to Cygnus for providing such wonderful product for cummunity, and
emphasize on its technological properties, hoping to discuss different
ways to solve different problems, which eventually may lead to
improvement of product.

   Well, how I worked around (or going to, it's work in progress)
above three problems with pids:
1. Just negating native pid on win9x. Since 9x pid is pointer to some
process block residing in kernel space (above 0x80000000) xored with
some value 0x7fxxxxxx, result will be positive. It however may be
large, but what to do? Well, it gave me headache with porting ash,
which used short to store pid. However, for the rest of well-mannered
apps which use pid_t it give no problems. Also, it's easy for human.
2. While there's no documented way, there's well documented
undocumented way by using native api.
3. Signal watcher of exec stump process should be told to act as
proxy, forwarding signals from exec() child to fork() parent.

   But I don't tell that above is suitable for cygwin, only that it
allows (does it?) to use almost unchanged native pids as posix pids.
For me, it gives following benefits:

1. Simply less kludging - there're pids provided by system and I use
them.
2. Same pid namespace with native apps - it's possible at least to
SIGKILL native app.
3. No need for mapping superstructures.

   Whether these points would be applicable to Cygwin is for sure
cannot be reasoned out by me. For example, 3 is not applicable, since
Cygwin implements process groups, and since win32 process groups are
rather naive, to implement them there needed superstructures anyway.

CF> Probably the most annoying feature of cygwin for me is that people seem
CF> to be compelled to criticize it while offering only vague generalities
CF> and smug assertions that they could do it better.

    Sorry, you told it before and now I'm personally writing working
code. Unfortunately, not for cygwin ;-(

    But whole point is not correct imho. For example, I see that
Cygwin improves with each release, moreover misfeatures which annoyed
me personally (as well as some other people, of course) are lifted.
That means that you listen to what people say and that's specific
enough to work out. Also, whenever I take a look at develop archives,
I see sufficiently enough new features proposed. Unfortunately, some
are ruled out.

    And last note about criticizing at all. It's only my perception,
but I see that mailing list traffic consist of following: discussions
of software ported to Cygwin (not Cigwin per se), then Cygwin-specific
features, then things people overlooked in faq, or which just haven't
made their way to, then thanks. As for criticism, there's not so much
of it to worry about to much. That's probably would be interesting if
noone would care to provide one. Well, I care, maybe to my harm.

CF> Before you offer the standard response of "I'm too busy", just take a
CF> moment to reflect on what that statement means.

    Unfortunately, "busy" will be only half-true in my case. I'm just
too weak and burdened with stupid problems poured at me by place I
live in.

CF> If you are too busy to
CF> actually investigate these "problems" and offer concrete solutions, then
CF> why should I believe that your ideas have any merit whatsoever?  How can
CF> you adequately criticize something that you don't understand?

    But I spend my time understanding, investigating and designing
solutions for these problems. I have drive for that. But coping with
building large foreign systems, submitting patches and argueing
they're really needed requires motivation, which luxury is not
effordable here. So, I just knead my crap in the conner, hoping that
some findings may be interesting for others.

CF> Ah.  The next argument will be that you have already implemented your
CF> own POSIX-on-Windows and know everything that Cygwin did wrong.

    Not everyting. But instead, I know where I'm doing wrong. And
that again and again makes me think that having all in one, confirmed
implementation would be better and regret that I'm noone to do that. But
still, it makes to want to "criticize" in hope that other people will
do that. Myself I just do what I'm best at - hack.

CF>   So,
CF> ok.  I'm willing to listen to how you mapped UNIX signals onto what
CF> Win32 offers.

    I used message queues and PostThreadMessage(). As an extra
feature, it allows to SIGTERM native windowed apps gracefully. But
that's only useful mapping to window messages, since WM_QUIT is only
message which works without explicit window id.

CF>   I'll be interested in hearing how you got exec() working.

      Well, I don't try to write my own PE loader to overlay existing
image ;-)

CF> You probably have implemented a fork.  I'd be interested in hearing how
CF> it differs substantially from what cygwin offers.

    It doesn't engage in long chats between parent and child. Parent
just prepares everything, starts child, sleeps, child clones memory
and awakens parent. Keeping in mind that it has no support for
dlopen'ed modules, its about 40% faster that cygwin's (not so bif
figure, imho).

CF>   Hmm.  You disparage
CF> the cygwin mount table.  Let's hear how you have tackled this problem.

    I disparage not mount table, but way it was automatically setup in
up to b20. While I personally don't use it, many people do since it's of
course useful.

    What I really can give criticism for is /cygdrive/ syntax. Reason
for that is simple - that "cygdrive" is path component but *do not*
maps to anything real in underlying file system. Some programs
traverse path themselves, statting each component. Proverbial ash is
example. So, to make it work it either requires to patch app itself or
provide workaround in libc. That won't happen if you've chosen other
syntax. As I did, I support /cygdrive/ syntax but it's deprecated, and
/mnt_<drive>/ is recommended (btw, 'mnt_' part is not changable, I
don't want incompatibilities between installations).

CF> I don't consider any of this off-topic for this mailing list.

    Nice to here.

CF>   I envision
CF> that you will probably want to enlighten us all with a series of articles
CF> on how it could all be done better, complete with actual code samples.

    Of course, no. Just sometimes, in the spirit of the moment, I do
write some, probaly awkward, but in no way wanting to be jeering,
message. Something like "am thinkink it is pain in neck. she is...", etc.
;-)

CF> Since this will be a substantial work, I guarantee that I will set aside
CF> a portion of my day, every day to read and analyze what you post.  In fact,
CF> I'm quite looking forward to your submissions.  Although you're probably
CF> too busy to provide cygwin patches, I expect that your insightful articles
CF> will still provide substantial fodder for future cygwin development.

    Hardly substantial, but maybe someone will really be interested.

CF> cgf



--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135



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

Re: Cygwin 1.1.0 gdb troubles

[Chris Faylor]

On Thu, Apr 20, 2000 at 10:18:34PM +0300, Paul Sokolovsky wrote:
>Chris Faylor <cgf@cygnus.com> wrote:
>>>difference: remove() explicitly states possibility of removing opened
>>>file, while DeleteFile() explicitly prohibits it. I can't believe
>
>CF> So, how do you work around this tiny little flaw then?  How does your
>CF> magic wand work?
>
>    Bad metaphor, it's for sure not magic, just pure technology, and
>hardly can be considered sufficiently advanced. So, currently I just
>ignore such error condition. So, after typical configure session with
>bash tens of orphaned files lie in /tmp. That sucks. I already made
>support for close-on-exec, but instead of set of flags I used array of
>fds which need to closed. So, one sweet day I will re-make it as
>arrays of flags, add new should-be-deleted on close flag to it. Then,
>close() will check that flag and delete that file. Well, but how I
>will get filename to delete? I know of no way to get it by handle, and
>I'm not going to store filename for each opened file.

Doesn't that sort of discount your assertions that it could all be done
much more easily using simple Win32 calls?

>>>Well, what idiosyncratic features of native pids would harden
>>>their usage as POSIX pisd as-is?
>>>
>>>1. While NT's pids are rather POSIX-correct as-is, 9x's ones are
>>>negative values, large (up to 10 dec digits) by module.
>>>2. There's no documented way to get ppid on NT.
>>>3. It's impossible to overlay image of current process. This means,
>>>when performing usual fork-exec chain, there will be three processes:
>>>parent, exec() implementer stub and execed child. So, between child
>>>and parent in POSIX terms there will be other process.
>
>CF>I'd like to hear your workaround for these problems.  Really.  I'm eager
>CF>to incorporate your advanced thinking into cygwin's design.  Or are you
>CF>just here to poke fun and jeer?
>
>   Well, how I worked around (or going to, it's work in progress)
>above three problems with pids:
>2. While there's no documented way, there's well documented
>undocumented way by using native api.

This was the gold I was trying to mine.  What's the "undocumented" way of
using the native API?

>3. Signal watcher of exec stump process should be told to act as
>proxy, forwarding signals from exec() child to fork() parent.

So you have two processes for every exec.  Ouch.

>But whole point is not correct imho.  For example, I see that Cygwin
>improves with each release, moreover misfeatures which annoyed me
>personally (as well as some other people, of course) are lifted.  That
>means that you listen to what people say and that's specific enough to
>work out.  Also, whenever I take a look at develop archives, I see
>sufficiently enough new features proposed.  Unfortunately, some are
>ruled out.

Specifically?

>CF> You probably have implemented a fork.  I'd be interested in hearing how
>CF> it differs substantially from what cygwin offers.
>
>It doesn't engage in long chats between parent and child.  Parent just
>prepares everything, starts child, sleeps, child clones memory and
>awakens parent.  Keeping in mind that it has no support for dlopen'ed
>modules, its about 40% faster that cygwin's (not so bif figure, imho).

This is just about the same as what cygwin does.  I don't know where you
got the idea that there are "long chats" between the parent and the child.

>CF>   Hmm.  You disparage
>CF> the cygwin mount table.  Let's hear how you have tackled this problem.
>
>    I disparage not mount table, but way it was automatically setup in
>up to b20. While I personally don't use it, many people do since it's of
>course useful.

There is actually no difference in the net release, AFAIK.

>What I really can give criticism for is /cygdrive/ syntax.  Reason for
>that is simple - that "cygdrive" is path component but *do not* maps to
>anything real in underlying file system.  Some programs traverse path
>themselves, statting each component.  Proverbial ash is example.  So,
>to make it work it either requires to patch app itself or provide
>workaround in libc.  That won't happen if you've chosen other syntax.
>As I did, I support /cygdrive/ syntax but it's deprecated, and
>/mnt_<drive>/ is recommended (btw, 'mnt_' part is not changable, I
>don't want incompatibilities between installations).

You're welcome to create /cygdrive if that is a problem or change /cygdrive
to /mnt, if that's an issue.

Anyway, you're describing a bug which can be fixed.  Thanks for reporting it.

cgf

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

Re: Cygwin 1.1.0 gdb troubles

[Chris Faylor]

On Wed, Apr 19, 2000 at 09:01:38AM -0400, Christopher Jones wrote:
>Seems like it would make more sense to at least hide these cygwin pids
>and let users always use windows pids for ps, kill, $$ in a shell, etc.
>So the PID and PPID values would be the real windows values and cygwin
>pids would disappear into the internals somewhere...  probably a lookup
>table if you really need to have them still.  Something like this would
>be more seemless, wouldn't it?

The main reason for cygwin pids is that there is no corresponding
exec*() style interface in Win32 land.  Most programs which use fork/exec
also rely on the fact that the exec'ed process has the same PID as the
fork.  There is no way to do this using the Win32 API.

cgf

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

RE: Cygwin 1.1.0 gdb troubles

[Christopher Jones]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

Title: RE: Cygwin 1.1.0 gdb troubles





> 
> The main reason for cygwin pids is that there is no corresponding
> exec*() style interface in Win32 land.  Most programs which 
> use fork/exec
> also rely on the fact that the exec'ed process has the same PID as the
> fork.  There is no way to do this using the Win32 API.


Thanks for the explanation Chris.  It had been a while since I dealt with fork/exec and I'd forgotten how much they rely on a certain PID behavior.  So the only other way to go would be to assign win32 processes cygwin pids which would probably lead to more yuckiness; and maybe there is not a way to muck with the internals of windows such that cygwin is always resident and receiving notification of new win32 process/thread creation.  Ick.  Oh well.  :)

Brian

Re: Cygwin 1.1.0 gdb troubles

[Chris Faylor]

On Wed, Apr 19, 2000 at 01:44:53PM -0400, Christopher Jones wrote:
>>The main reason for cygwin pids is that there is no corresponding
>>exec*() style interface in Win32 land.  Most programs which use
>>fork/exec also rely on the fact that the exec'ed process has the same
>>PID as the fork.  There is no way to do this using the Win32 API.
>
>Thanks for the explanation Chris.  It had been a while since I dealt
>with fork/exec and I'd forgotten how much they rely on a certain PID
>behavior.  So the only other way to go would be to assign win32
>processes cygwin pids which would probably lead to more yuckiness; and
>maybe there is not a way to muck with the internals of windows such
>that cygwin is always resident and receiving notification of new win32
>process/thread creation.  Ick.  Oh well.  :)

I believe that it is possible to wedge cygwin into the process creation
part of Windows NT, at least, but, I dunno... it just seems wrong.

I've been trying hard, since I first started working on cygwin three
years ago, to come up with some way to get rid of the artificial pids,
but so far, I haven't thought of anything.

That's why I'll be so interested in hearing about Paul Sokolovsky's
breakthrough.

cgf

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