* RE: Cygwin 1.1.0 gdb troubles
@ 2000-04-19 10:45 Christopher Jones
2000-04-19 10:49 ` Chris Faylor
0 siblings, 1 reply; 21+ messages in thread
From: Christopher Jones @ 2000-04-19 10:45 UTC (permalink / raw)
To: cygwin
[-- 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Cygwin 1.1.0 gdb troubles 2000-04-19 10:45 Cygwin 1.1.0 gdb troubles Christopher Jones @ 2000-04-19 10:49 ` Chris Faylor 0 siblings, 0 replies; 21+ messages in thread From: Chris Faylor @ 2000-04-19 10:49 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: Cygwin 1.1.0 gdb troubles
@ 2000-04-19 6:02 Christopher Jones
2000-04-19 7:15 ` Re[2]: " Paul Sokolovsky
2000-04-19 9:47 ` Chris Faylor
0 siblings, 2 replies; 21+ messages in thread
From: Christopher Jones @ 2000-04-19 6:02 UTC (permalink / raw)
To: Heribert Dahms, 'cygwin@sourceware.cygnus.com'
[-- 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re[2]: Cygwin 1.1.0 gdb troubles 2000-04-19 6:02 Christopher Jones @ 2000-04-19 7:15 ` Paul Sokolovsky 2000-04-19 7:22 ` DJ Delorie 2000-04-19 10:05 ` Chris Faylor 2000-04-19 9:47 ` Chris Faylor 1 sibling, 2 replies; 21+ messages in thread From: Paul Sokolovsky @ 2000-04-19 7:15 UTC (permalink / raw) To: Christopher Jones; +Cc: cygwin 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Cygwin 1.1.0 gdb troubles 2000-04-19 7:15 ` Re[2]: " Paul Sokolovsky @ 2000-04-19 7:22 ` DJ Delorie 2000-04-19 12:19 ` Re[2]: " Paul Sokolovsky 2000-04-19 10:05 ` Chris Faylor 1 sibling, 1 reply; 21+ messages in thread From: DJ Delorie @ 2000-04-19 7:22 UTC (permalink / raw) To: paul-ml; +Cc: cbjones, cygwin > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re[2]: Cygwin 1.1.0 gdb troubles 2000-04-19 7:22 ` DJ Delorie @ 2000-04-19 12:19 ` Paul Sokolovsky 2000-04-19 12:31 ` DJ Delorie 2000-04-19 16:27 ` Chris Faylor 0 siblings, 2 replies; 21+ messages in thread From: Paul Sokolovsky @ 2000-04-19 12:19 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Cygwin 1.1.0 gdb troubles 2000-04-19 12:19 ` Re[2]: " Paul Sokolovsky @ 2000-04-19 12:31 ` DJ Delorie 2000-04-19 16:27 ` Chris Faylor 1 sibling, 0 replies; 21+ messages in thread From: DJ Delorie @ 2000-04-19 12:31 UTC (permalink / raw) To: paul-ml; +Cc: cygwin > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Cygwin 1.1.0 gdb troubles 2000-04-19 12:19 ` Re[2]: " Paul Sokolovsky 2000-04-19 12:31 ` DJ Delorie @ 2000-04-19 16:27 ` Chris Faylor 1 sibling, 0 replies; 21+ messages in thread From: Chris Faylor @ 2000-04-19 16:27 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Cygwin 1.1.0 gdb troubles 2000-04-19 7:15 ` Re[2]: " Paul Sokolovsky 2000-04-19 7:22 ` DJ Delorie @ 2000-04-19 10:05 ` Chris Faylor 2000-04-20 23:37 ` Re[2]: " Paul Sokolovsky 1 sibling, 1 reply; 21+ messages in thread From: Chris Faylor @ 2000-04-19 10:05 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re[2]: Cygwin 1.1.0 gdb troubles 2000-04-19 10:05 ` Chris Faylor @ 2000-04-20 23:37 ` Paul Sokolovsky 2000-04-21 8:08 ` Chris Faylor 0 siblings, 1 reply; 21+ messages in thread From: Paul Sokolovsky @ 2000-04-20 23:37 UTC (permalink / raw) To: Chris Faylor 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Cygwin 1.1.0 gdb troubles 2000-04-20 23:37 ` Re[2]: " Paul Sokolovsky @ 2000-04-21 8:08 ` Chris Faylor 0 siblings, 0 replies; 21+ messages in thread From: Chris Faylor @ 2000-04-21 8:08 UTC (permalink / raw) To: 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Cygwin 1.1.0 gdb troubles 2000-04-19 6:02 Christopher Jones 2000-04-19 7:15 ` Re[2]: " Paul Sokolovsky @ 2000-04-19 9:47 ` Chris Faylor 1 sibling, 0 replies; 21+ messages in thread From: Chris Faylor @ 2000-04-19 9:47 UTC (permalink / raw) To: 'cygwin@sourceware.cygnus.com' 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: Cygwin 1.1.0 gdb troubles
@ 2000-04-18 15:04 Heribert Dahms
0 siblings, 0 replies; 21+ messages in thread
From: Heribert Dahms @ 2000-04-18 15:04 UTC (permalink / raw)
To: 'cygwin@sourceware.cygnus.com'
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: Cygwin 1.1.0 gdb troubles
@ 2000-04-18 14:32 Heribert Dahms
2000-04-18 14:39 ` Chris Faylor
0 siblings, 1 reply; 21+ messages in thread
From: Heribert Dahms @ 2000-04-18 14:32 UTC (permalink / raw)
To: 'cygwin@sourceware.cygnus.com'
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Cygwin 1.1.0 gdb troubles 2000-04-18 14:32 Heribert Dahms @ 2000-04-18 14:39 ` Chris Faylor 0 siblings, 0 replies; 21+ messages in thread From: Chris Faylor @ 2000-04-18 14:39 UTC (permalink / raw) To: 'cygwin@sourceware.cygnus.com' 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: Cygwin 1.1.0 gdb troubles
@ 2000-04-18 14:11 Heribert Dahms
2000-04-18 14:26 ` Chris Faylor
0 siblings, 1 reply; 21+ messages in thread
From: Heribert Dahms @ 2000-04-18 14:11 UTC (permalink / raw)
To: 'cygwin@sourceware.cygnus.com'
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Cygwin 1.1.0 gdb troubles 2000-04-18 14:11 Heribert Dahms @ 2000-04-18 14:26 ` Chris Faylor 0 siblings, 0 replies; 21+ messages in thread From: Chris Faylor @ 2000-04-18 14:26 UTC (permalink / raw) To: 'cygwin@sourceware.cygnus.com' 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Cygwin 1.1.0 gdb troubles @ 2000-04-17 21:32 Boyd Adamson 2000-04-17 21:47 ` Chris Faylor 0 siblings, 1 reply; 21+ messages in thread From: Boyd Adamson @ 2000-04-17 21:32 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Cygwin 1.1.0 gdb troubles 2000-04-17 21:32 Boyd Adamson @ 2000-04-17 21:47 ` Chris Faylor 2000-04-17 22:30 ` Chris Faylor 2000-04-18 6:12 ` Tim Prince 0 siblings, 2 replies; 21+ messages in thread From: Chris Faylor @ 2000-04-17 21:47 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Cygwin 1.1.0 gdb troubles 2000-04-17 21:47 ` Chris Faylor @ 2000-04-17 22:30 ` Chris Faylor 2000-04-17 23:41 ` Boyd Adamson 2000-04-18 6:12 ` Tim Prince 1 sibling, 1 reply; 21+ messages in thread From: Chris Faylor @ 2000-04-17 22:30 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: Cygwin 1.1.0 gdb troubles 2000-04-17 22:30 ` Chris Faylor @ 2000-04-17 23:41 ` Boyd Adamson 2000-04-18 12:29 ` Chris Faylor 0 siblings, 1 reply; 21+ messages in thread From: Boyd Adamson @ 2000-04-17 23:41 UTC (permalink / raw) To: cygwin > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Cygwin 1.1.0 gdb troubles 2000-04-17 23:41 ` Boyd Adamson @ 2000-04-18 12:29 ` Chris Faylor 0 siblings, 0 replies; 21+ messages in thread From: Chris Faylor @ 2000-04-18 12:29 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Cygwin 1.1.0 gdb troubles 2000-04-17 21:47 ` Chris Faylor 2000-04-17 22:30 ` Chris Faylor @ 2000-04-18 6:12 ` Tim Prince 2000-04-18 13:17 ` Chris Faylor 1 sibling, 1 reply; 21+ messages in thread From: Tim Prince @ 2000-04-18 6:12 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Cygwin 1.1.0 gdb troubles 2000-04-18 6:12 ` Tim Prince @ 2000-04-18 13:17 ` Chris Faylor 0 siblings, 0 replies; 21+ messages in thread From: Chris Faylor @ 2000-04-18 13:17 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2000-04-21 8:08 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-04-19 10:45 Cygwin 1.1.0 gdb troubles Christopher Jones 2000-04-19 10:49 ` Chris Faylor -- strict thread matches above, loose matches on Subject: below -- 2000-04-19 6:02 Christopher Jones 2000-04-19 7:15 ` Re[2]: " Paul Sokolovsky 2000-04-19 7:22 ` DJ Delorie 2000-04-19 12:19 ` Re[2]: " Paul Sokolovsky 2000-04-19 12:31 ` DJ Delorie 2000-04-19 16:27 ` Chris Faylor 2000-04-19 10:05 ` Chris Faylor 2000-04-20 23:37 ` Re[2]: " Paul Sokolovsky 2000-04-21 8:08 ` Chris Faylor 2000-04-19 9:47 ` Chris Faylor 2000-04-18 15:04 Heribert Dahms 2000-04-18 14:32 Heribert Dahms 2000-04-18 14:39 ` Chris Faylor 2000-04-18 14:11 Heribert Dahms 2000-04-18 14:26 ` Chris Faylor 2000-04-17 21:32 Boyd Adamson 2000-04-17 21:47 ` Chris Faylor 2000-04-17 22:30 ` Chris Faylor 2000-04-17 23:41 ` Boyd Adamson 2000-04-18 12:29 ` Chris Faylor 2000-04-18 6:12 ` Tim Prince 2000-04-18 13:17 ` Chris Faylor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).