Re: Cygwin.dll crash, alloca and custom stack
Yes, I know. Unless I implement this *crucial* bit of functionality it is possible that the space time continuum will implode. I see, so any API that you personally have no use for should be mocked. However, since it is not currently implemented, since there is no sign of an implementation on the horizon, and since it may be impossible to implement for Windows, that does present a problem for your implementation on cygwin. Not an intractable problem, it just means that I need to allocate a little extra space in any stacks, enough to run any signal handlers that I install. However, I'm not sure you can rely on the fact that the frame pointer is being used for everything, especially if the code is near the function prologue. I suggested before that maybe you should mention what you're doing in the gcc mailing list. I'm sure that people there would tell you if what you are doing is safe. Ok. Using posix threads is going to be quite a bit more portable than writing assembly language to set ESP, especially if you branch out into non-x86 platforms. Oh yeah, I suppose. But it would mean I'd need a mutex for every function call, and on every function call would have to wait on on the mutex for the function to return. It would also mean every calling function would need to wait for a timeslice before it could return. So if I called some function 100 times in a loop, I'd have to wait 100 times for process scheduling. That would make performance suck very big time. - If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin.dll crash, alloca and custom stack
On Aug 15 16:52, Bitmead, Chris wrote: Yes, I know. Unless I implement this *crucial* bit of functionality it is possible that the space time continuum will implode. I see, so any API that you personally have no use for should be mocked. However, since it is not currently implemented, since there is no sign of an implementation on the horizon, and since it may be impossible to implement for Windows, that does present a problem for your implementation on cygwin. Translation: http://cygwin.com/acronyms/#SHTDI http://cygwin.com/acronyms/#PTC Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin.dll crash, alloca and custom stack
On Mon, Aug 15, 2005 at 04:52:16PM +1000, Bitmead, Chris wrote: On Mon, Aug 15, 2005 at 01:21:41AM -0400, Christopher Faylor wrote: On Mon, Aug 15, 2005 at 02:56:44PM +1000, Bitmead, Chris wrote: I've heard of sigstack and sigalstack but cygwin hasn't. Well that's a shame since sigaltstack is part of the base specification for X/Open UNIX. If cygwin wants to become UNIX compatible it needs to implement it. Yes, I know. Unless I implement this *crucial* bit of functionality it is possible that the space time continuum will implode. I see, so any API that you personally have no use for should be mocked. This is just my standard humorous reply to people who imply that something needs to be done in this open source project. We do see people here who insist that a certain missing feature should be made available, with the seeming implication that we'd better get off our asses and do something about it if cygwin wants to be taken seriously, The sarcasm meter gets set a little higher when someone tells me that I need to do something after I've told them that I'm familiar with the functionality. Anyway, I think that's it for me. I've given you enough information and misinformation. Good luck. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Cygwin.dll crash, alloca and custom stack
From: Gary R. Van Sickle wrote: In the post you're replying to, I listed the legitimate reasons for wanting to do it. Here they are again: - If you're writing a task switcher. And what's the difference between a task switcher and switching between co-routines? You seem to already have all the answers you ostensibly came here to seek, so I expect you'll be answering that question for me. Basically nothing at all My expectation has been fulfilled. except that a task gets switched whenever the OS wants to, whereas a co-routine gets switched under program control. Really? So these coroutines are totally under the Scheme programmer's control, the OS has nothing to do with them, but if I, say, spawn a thread, it's off to never-never land and I have no control over it? So why must they be implemented differently? I guess they musn't. As you've already figured out, you should use the platform's existing task switching facilities to implement these coroutines, and drop this silly notion of manhandling esp. It's nothing new to be writing user space task switchers that switch stacks, When was the last time you did it on either Windows or Linux with gcc? I see no reason why a user space co-routine switcher should not do the same. That's because you're looking the other way. Do you actually realize that there are far better ways to implement stacks for interpreters than dinking with esp? I realise there are a dozen ways to suck eggs. I thought your goal was to write a Scheme interpreter with as little pain as possible. But do YOU realise If I do, I don't care. I'm not the one who came here for help and then became belligerent when it was offered. that there are two ways to implement a language with co-routines, whether it be interpreted or compiled, and that is to either have a vm with a fake stack, or to use the machine's real stack. Or to spawn the coroutine as a thread (or fiber) as Chris Faylor pointed out, and let the OS and CRT operate as they were designed to operate. And if you use the machine's real stack you MUST dink with esp. You MUST. Then you'd better not use the machine's real stack. I don't happen to be writing a VM based interpreter with a fake stack. Chris, you're so wildly out in left field on this no-brainer issue that there's no way you'll be writing any sort of interpreter. I suggest you investigate those alternatives instead of trying to do something that cannot work, and then getting all pissy when people try to dissuade you from wasting your time. That's strange. Now that I know that on Windows it likes to use its own stack for system calls, its working fine by just restoring the system stack temporarily. I can switch stacks and co-routines with no problems at all. So much for your bogus cannot work. I guess you don't know everything after all huh? I guess it is in fact you who knows all. I stand humbled, and hope that your esp-mangling-via-gcc-asm()-statements Scheme interpreter works as well tomorrow as it did today. I do remain curious why Windows actually cares whereas Linux acts sensibly and doesn't carebut it matters little for my purposes. ...until something goes wrong, which it will, and you can't figure out why. But I guess you can be assured that it has nothing whatsoever to do with manhandling esp, so you have that going for you, which is nice. No, but there is a law that you have to learn to walk before you can run. You are trying to sprint a marathon before you're even able to stand erect. Meaningless ad-hominem. You refuse to acknowledge that C has a runtime. There was nothing meaningless about that ad-hominem, Mr. Sees-An-Insult-Under-Every-Metaphor. I guess now that I've got it working, if I can't stand erect, you must not even be crawling. SNAP!, as the kids say these days. Christopher Faylor cgf-no-personal-reply-please at cygwin dot com wrote: What you are trying to do is a bad idea. Bad huh? I'm fuzzy on the whole good/bad thing. Care to elaborate? Dinking with esp via asm() statements: bad. Combining replies to two different posts into one: bad. Learning how to write code that at least has a fighting chance of not being a disaster: good. Btw, have you thought about how to handle stack overflow? What happens when the program pushes its way to the top of your malloced region? Each Scheme function call has its own environment that is chained to previous environments. Each environment has its own stack. The C code that executes a scheme function uses a small and well-defined amount of stack. Restoring the system stack for external library calls is going to be a good idea anyway, because they can use arbitrary amounts of stack. Wow. Yeah, well, I guess that is technically on the list of reasons not to be screwing around with your stack pointer in C code, somewhere down around #431. But for the
RE: Cygwin.dll crash, alloca and custom stack
[snip a lot of jibba-jabba] And, I assume that there will be no recursion in your program? Because if there is you're guaranteed heap corruption. No, each function call has its own scheme environment and therefore its own stack. So on a recursive call a new environment is allocated and thus a new stack is allocated. Of course, most scheme recursion is tail calls and that will be implemented with longjmp, thus re-using the same stack. By allocating my own stacks I can longjmp down the stack (conceptually), which is normally a no-no, but I've shown to work fine if you allocate your own chain of stacks that are not garbage collected till they have no references. Is there going to be any part of this interpreter that isn't a no-no? You're going to longjmp() around all your crazy malloc'd stacks? Seriously Chris, how is it that you can come up with all these wild... Schemes... and yet you can't just admit you've taken a wrong turn at Albequerque and do things in a sane way? Whatever, I'm with Faylor. Good luck, and good night nurse. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin.dll crash, alloca and custom stack
On Mon, Aug 15, 2005 at 09:31:12PM -0500, Gary R. Van Sickle wrote: Is there going to be any part of this interpreter that isn't a no-no? You're going to longjmp() around all your crazy malloc'd stacks? Seriously Chris, how is it that you can come up with all these wild... Schemes... and yet you can't just admit you've taken a wrong turn at Albequerque and do things in a sane way? No, it's perl that longjmps around crazy malloc'd stacks. But at least it doesn't set registers to them, and is slow as molasses because of it. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Cygwin.dll crash, alloca and custom stack
Anyway, this similar code does work under Linux, or at least it appears to: It's a long walk from at least appears to work to does work. Are you saying it doesn't work, or are you just generally in a grumpy mood? ...? I'm saying exactly what I said. I'm in no particular mood. While I don't claim to be an uber-expert in assembler, I know I didn't jump into space. Yeah dude, you did. You pulled the rug out from under the C runtime, Cygwin, and apparently even the OS. It is not within the jurisdiction of a C program to do that. Uh, C doesn't have a runtime. Ubboy. Dude, you just showed the class that you have about 5 to 10 years more baking to do before the notion of dinking with esp should even be crossing your mind. And as you noticed, this is not a pure C program. Is there some law that I have to write pure C programs? No, but there is a law that you have to learn to walk before you can run. You are trying to sprint a marathon before you're even able to stand erect. As to whether I'm pulling the rug out from the OS, there is no reason to assume that should be so. There is no reason why an OS should particularly care where I put my stack. The world doesn't revolve around the C language's assumptions, Actually a large part of it does, but that's immaterial to our current discussion. but it could well be that Windows does care. That's why I'm asking my question here. Not so that you can express your general dissatisfaction with non-C programmers, but so that people who might actually know can speak up. I actually know. There is no reason you should be worrying about esp given: - The program you're writing. - Your level of knowledge of the C language, compilers, runtimes, Cygwin, and Oses. You are attacking the wrong problem in the wrong way. That is the best way to guarantee disaster. Since I suspect you do not wish disaster, I and others are trying to point that fact out to you. I've written task switching programs in C under DOS that switch stacks with no problem. Neither Windows nor Linux is DOS. This is true, but so what? So what? DOS was not even an OS, it was a single-threaded filesystem and program loader. The other two do their own task switching. Unless you have specific information that Windows or Linux cares, you are just being grumpy. Or helpful, as the case may be. What Korny said: what you're trying to do is nuts. Whether what I want to do will work or not is one thing. But telling me that trying to do it is nuts, is.. well nuts. Telling you the truth is nuts? Well, since you don't seem to want to listen to simple facts, maybe you're right. How in heck would you know if trying to do such a thing is nuts? Because I've both written interpreters and manipulated system stack pointers, and I know that there is no connection between the two. Just because you don't understand the legitimate reasons for wanting to do it doesn't mean that it is. In the post you're replying to, I listed the legitimate reasons for wanting to do it. Here they are again: - If you're writing a task switcher. You're not doing any of the things on that list, are you? If not, then you have no legitimate reason to be trying to dink with esp in the way that you are. There's no more to understand. Frankly I'd be surprised if gcc is even putting the asm() statements in the resulting machine code unmolested. You seem to be surprised by a lot of things. Mainly by how pointing out simple facts to you throws you into such a silly rage. This ain't the Good Old Days, and you're not writing a task switcher, which is the only legitimate reason to be doing what you're trying to do. Oh yeah, you are some kind of god of computer science that you can pronounce judgements about what kind of things are legitimate? No, just an old country programmer who can recognize the wrong problem+wrong solution=disaster situation when he sees it. Do you actually realise that not all computer languages can be implemented with a model of one stack? Do you actually realize that there are far better ways to implement stacks for interpreters than dinking with esp? Ways that actually have a chance of working? I suggest you investigate those alternatives instead of trying to do something that cannot work, and then getting all pissy when people try to dissuade you from wasting your time. And don't make me break out my Turing Machine on you about that statement of yours. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin.dll crash, alloca and custom stack
On Sunday, August 14, 2005 1:47 AM [EDT], Chris wrote: Yeah dude, you did. You pulled the rug out from under the C runtime, Cygwin, and apparently even the OS. It is not within the jurisdiction of a C program to do that. Uh, C doesn't have a runtime. All major languages in use today have a runtime - C is no different. On UNIX/Linux, its mostly (if not always) called libc (glibc being the GNU variant used on most Linux systems). On Windows, its msvcrt.dll (and for newer programs built with the 1.1 .Net tools, msvcr71.dll, and 2.0 beta .Net tools, msvcrt80.dll). These shared libraries provide the interfaces, calls, etc that all C language programs need and use. In the case of Cygwin, it provides the C runtime for applications that use it - which means you wont be using msvcrt.dll (and IIRC from discussions here, programs linked against both will either 1. crash and burn and/or 2) function in unexpected ways). I believe that issue has been covered in at least one FAQ entry. If a binary is 100% free of dependancies (and its not done in assembly), it usually means that the runtime is statically linked with the binary (which also tends to bloat the binary up quite a bit in size). I've not seen situations like that under Windows very often (to be honest, never in my experience), since even programs written in assembly need to link with GDI.DLL, COMCTL32.DLL, WSOCK32.DLL, etc in order to provide a GUI interface through Windows or access the TCP/IP stack, or access files on the disk, and so on.. And, correct me if I am wrong, Microsoft doesn't allow you to statically link msvcrt.dll with your program. Someone was working on a open source/free software version of msvcrt.dll that was going to be a drop in replacement for the MS version - no idea how far it actually got. Though I see static linked binaries on Linux quite a bit with commercial programs that don't provide you with the source. Easier then providing 50 builds to support every distribution in use, since every distribtuon seems to use a different version of glibc that may or may not be fully compatible with the version the program was compiled and dynamically linked against. I am not a programmer - though I was in the past (I did Pascal on the Mac, as well as TurboPascal on DOS/Win 3.x, and earily Borland C++ on Windows 3.x). These days I just port apps from Linux to Windows using Cygwin, and I'm a Linux sysadmin. So, all my knowledge/experience on stuff like this is from what I've read on here or on the web, or from blowing up and repairing my desktop/laptop and server systems. I welcome corrections to my explanations obviously. -- Brian Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin.dll crash, alloca and custom stack
On Sun, Aug 14, 2005 at 03:47:45PM +1000, Chris wrote: The world doesn't revolve around the C language's assumptions, but it could well be that Windows does care. I already told you that Windows cares. There is no reason to speculate. That's why I'm asking my question here. Not so that you can express your general dissatisfaction with non-C programmers, but so that people who might actually know can speak up. And, I spoke up. What you don't seem to be getting is that the people who are responding actually do know what they're talking about. What you are trying to do is a bad idea. If you want stronger indication of that fact, you might try posting your ideas to the gcc mailing list. Btw, have you thought about how to handle stack overflow? What happens when the program pushes its way to the top of your malloced region? cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Cygwin.dll crash, alloca and custom stack
All major languages in use today have a runtime - C is no different. On UNIX/Linux, its mostly (if not always) called libc (glibc being the GNU variant used on most Linux systems). Well I don't think of libc as part of the C language proper because I spent a number of years programming in a version of C that didn't have any of the normal functions one normally associates with libc, like printf and all those other functions you'll find in the ansi standard. libc doesn't implement any of the features of the C language proper, unlike other languages that have a runtime that implements actual language features like garbage collectors, object systems and so on. libc is an optional library that you can choose to use or not use in your C program. If you want to include the standard library as part of C, then I suppose you could say it is a runtime, but that kindof makes runtime a meaningless term, when it includes pedestrian stuff like atoi. - If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Cygwin.dll crash, alloca and custom stack
From: Gary R. Van Sickle wrote: In the post you're replying to, I listed the legitimate reasons for wanting to do it. Here they are again: - If you're writing a task switcher. And what's the difference between a task switcher and switching between co-routines? Basically nothing at all except that a task gets switched whenever the OS wants to, whereas a co-routine gets switched under program control. So why must they be implemented differently? It's nothing new to be writing user space task switchers that switch stacks, I see no reason why a user space co-routine switcher should not do the same. Do you actually realize that there are far better ways to implement stacks for interpreters than dinking with esp? I realise there are a dozen ways to suck eggs. But do YOU realise that there are two ways to implement a language with co-routines, whether it be interpreted or compiled, and that is to either have a vm with a fake stack, or to use the machine's real stack. And if you use the machine's real stack you MUST dink with esp. You MUST. I don't happen to be writing a VM based interpreter with a fake stack. I suggest you investigate those alternatives instead of trying to do something that cannot work, and then getting all pissy when people try to dissuade you from wasting your time. That's strange. Now that I know that on Windows it likes to use its own stack for system calls, its working fine by just restoring the system stack temporarily. I can switch stacks and co-routines with no problems at all. So much for your bogus cannot work. I guess you don't know everything after all huh? I do remain curious why Windows actually cares whereas Linux acts sensibly and doesn't carebut it matters little for my purposes. No, but there is a law that you have to learn to walk before you can run. You are trying to sprint a marathon before you're even able to stand erect. Meaningless ad-hominem. I guess now that I've got it working, if I can't stand erect, you must not even be crawling. Christopher Faylor cgf-no-personal-reply-please at cygwin dot com wrote: What you are trying to do is a bad idea. Bad huh? I'm fuzzy on the whole good/bad thing. Care to elaborate? Btw, have you thought about how to handle stack overflow? What happens when the program pushes its way to the top of your malloced region? Each Scheme function call has its own environment that is chained to previous environments. Each environment has its own stack. The C code that executes a scheme function uses a small and well-defined amount of stack. Restoring the system stack for external library calls is going to be a good idea anyway, because they can use arbitrary amounts of stack. But for the interpreter itself the exact amount of stack required for one lambda can be calculated by trial and error. The other way to implement it is to copy the entire stack when switching co-routines, but I'm trying to avoid that. - If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin.dll crash, alloca and custom stack
On Mon, Aug 15, 2005 at 11:11:47AM +1000, Bitmead, Chris wrote: I suggest you investigate those alternatives instead of trying to do something that cannot work, and then getting all pissy when people try to dissuade you from wasting your time. That's strange. Now that I know that on Windows it likes to use its own stack for system calls, its working fine by just restoring the system stack temporarily. Your demonstration code didn't use any Windows system calls. You were calling cygwin functions. I notice that you save your stack pointer in an automatic variable (saved on the stack), reset the stack pointer, and then get it back again. You are relying on the fact that the frame pointer doesn't change in that scenario. That still seems sort of fragile to me. I can imagine that some gcc optimization will come along (if it hasn't already) which defaults to using -fomit-frame-pointer for some optimization and then your code will break. I do remain curious why Windows actually cares whereas Linux acts sensibly and doesn't carebut it matters little for my purposes. It is really not nonsensible for an OS to assume that it has control of the stack. Christopher Faylor cgf-no-personal-reply-please at cygwin dot com wrote: What you are trying to do is a bad idea. Bad huh? I'm fuzzy on the whole good/bad thing. Care to elaborate? I already did earlier. Let's not loop. Btw, have you thought about how to handle stack overflow? What happens when the program pushes its way to the top of your malloced region? Each Scheme function call has its own environment that is chained to previous environments. Each environment has its own stack. The C code that executes a scheme function uses a small and well-defined amount of stack. Restoring the system stack for external library calls is going to be a good idea anyway, because they can use arbitrary amounts of stack. But for the interpreter itself the exact amount of stack required for one lambda can be calculated by trial and error. The other way to implement it is to copy the entire stack when switching co-routines, but I'm trying to avoid that. And what happens when the compiler decides to allocate more memory on the stack than what seems possible from code inspection, like when there's a signal? That can consume quite a bit of stack space. And, I assume that there will be no recursion in your program? Because if there is you're guaranteed heap corruption. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin.dll crash, alloca and custom stack
Your demonstration code didn't use any Windows system calls. You were calling cygwin functions. And printf doesn't use a Windows system call to write its output?? I fully admit to being in the dark about whether it is Windows or cygwin that is being annoying here. I notice that you save your stack pointer in an automatic variable (saved on the stack), reset the stack pointer, and then get it back again. You are relying on the fact that the frame pointer doesn't change in that scenario. A valid observation. I may need to push the fp onto the new stack and pop it off before restoring. It is really not nonsensible for an OS to assume that it has control of the stack. Lots of claims flying around, but no justification. An OS specified stack can provide automatic extension to applications that are interested in that feature, but apart from that I don't see why it should give a rip what an app does with its stack. I already did earlier. Let's not loop. You said that Windows has the TIB area. Ok, but if I restore the system stack before talking to windows, I don't see any problem. And what happens when the compiler decides to allocate more memory on the stack than what seems possible from code inspection, like when there's a signal? Well you've heard of sigaltstack() right? That's an API where you call malloc() to create some stack space. But I guess that API is bad because it means that the OS is no longer controlling where the stack is right? And, I assume that there will be no recursion in your program? Because if there is you're guaranteed heap corruption. No, each function call has its own scheme environment and therefore its own stack. So on a recursive call a new environment is allocated and thus a new stack is allocated. Of course, most scheme recursion is tail calls and that will be implemented with longjmp, thus re-using the same stack. By allocating my own stacks I can longjmp down the stack (conceptually), which is normally a no-no, but I've shown to work fine if you allocate your own chain of stacks that are not garbage collected till they have no references. - If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin.dll crash, alloca and custom stack
On Mon, Aug 15, 2005 at 12:58:10PM +1000, Bitmead, Chris wrote: cgf wrote: It is really not nonsensible for an OS to assume that it has control of the stack. Lots of claims flying around, but no justification. An OS specified stack can provide automatic extension to applications that are interested in that feature, but apart from that I don't see why it should give a rip what an app does with its stack. The OS may care about where the stack lives and how it is laid out. Windows allocates memory in a special way when it creates the stack to allow automatic extension of the stack. The runtime may also care. Windows doesn't care, in the short term, if you reset esp. It doesn't store the stack pointer in the TIB but there are potential problems if you generate any type of exception. There is further potential in cygwin in the event of a cygwin signal. As I mentioned previously, cygwin uses the stack for thread local storage so you can't just create a new stack and expect things to work. You've worked around that by wrapping cygwin function calls with save/restore operations. That may work ok except in the case of signals. I already did earlier. Let's not loop. You said that Windows has the TIB area. Ok, but if I restore the system stack before talking to windows, I don't see any problem. I said more than that but, that's ok. And what happens when the compiler decides to allocate more memory on the stack than what seems possible from code inspection, like when there's a signal? Well you've heard of sigaltstack() right? That's an API where you call malloc() to create some stack space. But I guess that API is bad because it means that the OS is no longer controlling where the stack is right? I've heard of sigstack and sigalstack but cygwin hasn't. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin.dll crash, alloca and custom stack
On Sun, Aug 14, 2005 at 11:28:04PM -0400, Christopher Faylor wrote: On Mon, Aug 15, 2005 at 12:58:10PM +1000, Bitmead, Chris wrote: cgf wrote: It is really not nonsensible for an OS to assume that it has control of the stack. Lots of claims flying around, but no justification. An OS specified stack can provide automatic extension to applications that are interested in that feature, but apart from that I don't see why it should give a rip what an app does with its stack. The OS may care about where the stack lives and how it is laid out. Windows allocates memory in a special way when it creates the stack to allow automatic extension of the stack. The runtime may also care. I meant to mention that the gcc also cares about the stack pointer since when you do something like this: void * st1, *oldstack; st1 = (void *)malloc(5000) + 5000; asm(mov %%esp, %0 : =r (oldstack)); asm(mov %0, %%esp : : r (st1)); /* stack danger here */ you can no longer access any variables in the enclosing stack frame and, given optimization, you don't always know precisely where this block of code will show up wrt the rest of the code in the function. You may be able to control this, to some extent, with the use of the volatile keyword. Maybe I don't understand precisely what you're trying to do but it seems like you could get the behavior you're looking for by setting up some thread pools and just switching to a new thread when it is time to call one of these functions which needs its own stack. On Windows you could also use fibers, rather than threads, I believe. I also have to retract what I said earlier because, on reflection, I don't see how resetting a stack pointer would matter to a multi-threaded program since the stacks are local to individual threads and, as I mentioned, Windows only cares about the memory region of the stack, not the value of the current stack pointer. So, again, the only thing you may have to worry about are cygwin signals and windows exceptions. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin.dll crash, alloca and custom stack
As I mentioned previously, cygwin uses the stack for thread local storage so you can't just create a new stack and expect things to work. You've worked around that by wrapping cygwin function calls with save/restore operations. It's not clear to me why cygwin threads should care where their stack is. But doesn't matter, there are other good reasons to use the system stack before calling random C functions. I've heard of sigstack and sigalstack but cygwin hasn't. Well that's a shame since sigaltstack is part of the base specification for X/Open UNIX. If cygwin wants to become UNIX compatible it needs to implement it. you can no longer access any variables in the enclosing stack frame and, given optimization, you don't always know precisely where this block of code will show up wrt the rest of the code in the function. Actually, you can still access variables because variable are offset from fp, not esp. One can't use omit-frame-pointer, but I can't expect to be switching calling conventions when playing around with assembler. And the reason fp isn't a problem is because function calls automatically push fp onto the (new) stack, so it is restored on function return. You may be able to control this, to some extent, with the use of the volatile keyword. I can't see that this would help. Maybe I don't understand precisely what you're trying to do but it seems like you could get the behavior you're looking for by setting up some thread pools and just switching to a new thread when it is time to call one of these functions which needs its own stack. On Windows you could also use fibers, rather than threads, I believe. Quite possibly, but fiddling around with threads could well be a lot more overhead, and possibly even less portable. I don't particularly want to have a context switch happening every time I call a function in the interpreter. I'm not even sure if I could control the thread so that it can't be interrupted until it returns. But it is a possibility if other avenues become a problem. But it would feel more like an admission of failure about how I'm doing it if I had to do that. So, again, the only thing you may have to worry about are cygwin signals and windows exceptions. And what is the issue with windows exceptions? Is it another case of needing extra stack space for safety? - If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin.dll crash, alloca and custom stack
On Mon, Aug 15, 2005 at 02:56:44PM +1000, Bitmead, Chris wrote: I've heard of sigstack and sigalstack but cygwin hasn't. Well that's a shame since sigaltstack is part of the base specification for X/Open UNIX. If cygwin wants to become UNIX compatible it needs to implement it. Yes, I know. Unless I implement this *crucial* bit of functionality it is possible that the space time continuum will implode. However, since it is not currently implemented, since there is no sign of an implementation on the horizon, and since it may be impossible to implement for Windows, that does present a problem for your implementation on cygwin. you can no longer access any variables in the enclosing stack frame and, given optimization, you don't always know precisely where this block of code will show up wrt the rest of the code in the function. Actually, you can still access variables because variable are offset from fp, not esp. One can't use omit-frame-pointer, but I can't expect to be switching calling conventions when playing around with assembler. And the reason fp isn't a problem is because function calls automatically push fp onto the (new) stack, so it is restored on function return. Ack. You're right. I even made the point about the frame pointer and then lost it ten minutes later. However, I'm not sure you can rely on the fact that the frame pointer is being used for everything, especially if the code is near the function prologue. I suggested before that maybe you should mention what you're doing in the gcc mailing list. I'm sure that people there would tell you if what you are doing is safe. Maybe I don't understand precisely what you're trying to do but it seems like you could get the behavior you're looking for by setting up some thread pools and just switching to a new thread when it is time to call one of these functions which needs its own stack. On Windows you could also use fibers, rather than threads, I believe. Quite possibly, but fiddling around with threads could well be a lot more overhead, and possibly even less portable. Using posix threads is going to be quite a bit more portable than writing assembly language to set ESP, especially if you branch out into non-x86 platforms. I mentioned thread pools rather than thread because the thread pool technique reduces the overhead involved in setting up a thread for every function call. Using a thread pool would certainly be slower than simple function calls, though, that's a given, although if you are calling malloc for every new invocation of a function, there is overhead, there too. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Cygwin.dll crash, alloca and custom stack
From: Jason FU wrote:
No, it doesn't 'work fine' under Linux. In fact it doesn't work at all,
on any platform.
My apologies for sending something that doesn't work under Linux, but I had
something similar working, but I wanted to cut it down for the sake of the
mailing list, and I didn't have access to a Linux machine just then to test it
again.
Anyway, this similar code does work under Linux, or at least it appears to:
#include stdio.h
int main() {
void * st1, *oldstack;
st1 = (void *)malloc(5000) + 5000;
asm(mov %%esp, %0 : =r (oldstack));
asm(mov %0, %%esp : : r (st1));
a();
asm(mov %0, %%esp : : r (oldstack));
}
int a() {
printf(hello\n);
}
This is a cut down of a more complex bit of code that does a lot of switching
stacks and works fine on Linux but not cygwin.
Where on earth do you think main is going to return to after
you've discarded the old stack like that?
Yes I know I didn't restore the stack, because I wasn't trying to show what
happens when main returns, I was trying to show that printf crashes way before
that ever becomes an issue. I've left the stack restoring code in the above
version.
The stack is for the compiler's use, keep your hands off of it!
Uh, did you ask Linus Torvalds what he thinks about that?
You just threw away the stack and jumped into space. What did you expect
to happen?
While I don't claim to be an uber-expert in assembler, I know I didn't jump into
space. I've written task switching programs in C under DOS that switch stacks with
no problem.
Christopher Faylor wrote:
I would expect that a multi-threaded linux app would not like the above.
That may well be, but I can't see why. Multiple threads generally are just
saving and restoring the registers, and don't care what stack those registers
point to. In the old days with user space threading, I presume the user space
code would be doing what I'm trying to do and creating its own stack.
Windows stores information about the stack in offsets from the %fs register.
You may be onto something there. Maybe Windows checks with the TEB that the
stack hasn't overflowed and gets confused or something. Maybe restoring the
system stack before any system calls is the only work around. The following
code seems to work under cygwin. That work around might be fine for what I'm
doing. Will have to think about it.
#include stdio.h
#include setjmp.h
int main() {
void * st1, *oldstack;
st1 = (void *)malloc(5000) + 5000;
asm(mov %%esp, %0 : =r (oldstack));
asm(mov %0, %%esp : : r (st1));
a(oldstack);
asm(mov %0, %%esp : : r (oldstack));
fprintf(stderr, hello2\n);
}
int a(void * oldstack) {
void * savestack;
asm(mov %%esp, %0 : =r (savestack));
asm(mov %0, %%esp : : r (oldstack));
fprintf(stderr, hello\n);
asm(mov %%esp, %0 : =r (savestack));
}
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Cygwin.dll crash, alloca and custom stack
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Anyway, this similar code does work under Linux, or at least it appears to: It's a long walk from at least appears to work to does work. [snip] You just threw away the stack and jumped into space. What did you expect to happen? While I don't claim to be an uber-expert in assembler, I know I didn't jump into space. Yeah dude, you did. You pulled the rug out from under the C runtime, Cygwin, and apparently even the OS. It is not within the jurisdiction of a C program to do that. I've written task switching programs in C under DOS that switch stacks with no problem. Neither Windows nor Linux is DOS. What Korny said: what you're trying to do is nuts. Frankly I'd be surprised if gcc is even putting the asm() statements in the resulting machine code unmolested. Christopher Faylor wrote: I would expect that a multi-threaded linux app would not like the above. That may well be, but I can't see why. Multiple threads generally are just saving and restoring the registers, and don't care what stack those registers point to. In the old days with user space threading, I presume the user space code would be doing what I'm trying to do and creating its own stack. This ain't the Good Old Days, and you're not writing a task switcher, which is the only legitimate reason to be doing what you're trying to do. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Cygwin.dll crash, alloca and custom stack
Anyway, this similar code does work under Linux, or at least it appears to: It's a long walk from at least appears to work to does work. Are you saying it doesn't work, or are you just generally in a grumpy mood? While I don't claim to be an uber-expert in assembler, I know I didn't jump into space. Yeah dude, you did. You pulled the rug out from under the C runtime, Cygwin, and apparently even the OS. It is not within the jurisdiction of a C program to do that. Uh, C doesn't have a runtime. And as you noticed, this is not a pure C program. Is there some law that I have to write pure C programs? As to whether I'm pulling the rug out from the OS, there is no reason to assume that should be so. There is no reason why an OS should particularly care where I put my stack. The world doesn't revolve around the C language's assumptions, but it could well be that Windows does care. That's why I'm asking my question here. Not so that you can express your general dissatisfaction with non-C programmers, but so that people who might actually know can speak up. I've written task switching programs in C under DOS that switch stacks with no problem. Neither Windows nor Linux is DOS. This is true, but so what? Unless you have specific information that Windows or Linux cares, you are just being grumpy. What Korny said: what you're trying to do is nuts. Whether what I want to do will work or not is one thing. But telling me that trying to do it is nuts, is.. well nuts. How in heck would you know if trying to do such a thing is nuts? Just because you don't understand the legitimate reasons for wanting to do it doesn't mean that it is. Frankly I'd be surprised if gcc is even putting the asm() statements in the resulting machine code unmolested. You seem to be surprised by a lot of things. This ain't the Good Old Days, and you're not writing a task switcher, which is the only legitimate reason to be doing what you're trying to do. Oh yeah, you are some kind of god of computer science that you can pronounce judgements about what kind of things are legitimate? Do you actually realise that not all computer languages can be implemented with a model of one stack? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin.dll crash, alloca and custom stack
I'm writing an implemention of a scheme interpreter in C, and as people
familiar with that language know, it requires some stack manipulation. Now
to test this out I wrote a little program
#include stdio.h
int main() {
char * st1;
st1 = (void *)malloc(5000) + 5000;
asm(mov %0, %%esp : : r (st1));
fprintf(stderr, hello\n);
}
This program crashes silently and prints nothing under cygwin. However this
kind of thing works fine under Linux.
Now if I run it under gdb it says 0x610dfbb3 in cygwin1!_alloca () from
/usr/bin/cygwin1.dll
Which seems to indicate that the problem has something to do with alloca.
Q1. Does cygwin and gcc have a real stack based alloca, or is it a fake
simulation? Intuitively I assume that this kind of error would be caused by
the latter.
Q2. Why does this problem occur? My vague guess is that something in the
bootstrap code for cygwin calls alloca, and because of the memory layout of
stack and heap, creating a heap based stack makes it free it prematurely.
Q3. Shouldn't this be fixed in cygwin? While this is an unusual case, it
seems reasonable to me that a program should be able to create a new stack
if it wants to.
Q4. Is there any work around? I'm guessing that if cygwin uses a fake
alloca, then a better implementation would fix it, but is there any way to
substitute another one without actually rebuilding cygwin.dll (which I am
loath to do).
-
If you have received this transmission in error please notify us
immediately by return e-mail and delete all copies. If this e-mail
or any attachments have been sent to you in error, that error does
not constitute waiver of any confidentiality, privilege or copyright
in respect of information in the e-mail or attachments.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Cygwin.dll crash, alloca and custom stack
Bitmead, Chris Chris.Bitmead at ag.gov.au writes:
I'm writing an implemention of a scheme interpreter in C, and as people
familiar with that language know, it requires some stack manipulation. Now
to test this out I wrote a little program
#include stdio.h
int main() {
char * st1;
st1 = (void *)malloc(5000) + 5000;
asm(mov %0, %%esp : : r (st1));
fprintf(stderr, hello\n);
}
This program crashes silently and prints nothing under cygwin. However this
kind of thing works fine under Linux.
Now if I run it under gdb it says 0x610dfbb3 in cygwin1!_alloca () from
/usr/bin/cygwin1.dll
Which seems to indicate that the problem has something to do with alloca.
Q1. Does cygwin and gcc have a real stack based alloca, or is it a fake
simulation? Intuitively I assume that this kind of error would be caused by
the latter.
Q2. Why does this problem occur? My vague guess is that something in the
bootstrap code for cygwin calls alloca, and because of the memory layout of
stack and heap, creating a heap based stack makes it free it prematurely.
Q3. Shouldn't this be fixed in cygwin? While this is an unusual case, it
seems reasonable to me that a program should be able to create a new stack
if it wants to.
Q4. Is there any work around? I'm guessing that if cygwin uses a fake
alloca, then a better implementation would fix it, but is there any way to
substitute another one without actually rebuilding cygwin.dll (which I am
loath to do).
-
If you have received this transmission in error please notify us
immediately by return e-mail and delete all copies. If this e-mail
or any attachments have been sent to you in error, that error does
not constitute waiver of any confidentiality, privilege or copyright
in respect of information in the e-mail or attachments.
Do you mean the following:
=
[EMAIL PROTECTED] C++]$ cat stack.c
#include stdio.h
int main()
{
char * st1;
st1 = (void *)malloc(5000) + 5000;
asm(mov %0, %%esp : : r (st1));
fprintf(stderr, hello\n);
}
[EMAIL PROTECTED] C++]$ rm stack
[EMAIL PROTECTED] C++]$ cat stack.c
#include stdio.h
int main()
{
char * st1;
st1 = (void *)malloc(5000) + 5000;
asm(mov %0, %%esp : : r (st1));
fprintf(stderr, hello\n);
}
[EMAIL PROTECTED] C++]$ make stack
cc stack.c -o stack
[EMAIL PROTECTED] C++]$ ./stack
Segmentation fault
=
I just can see that your code crashes there in both cygwin and linux.
Jason
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Cygwin.dll crash, alloca and custom stack
Original Message
From: Jason FU
Sent: 12 August 2005 08:35
Bitmead, Chris Chris.Bitmead writes:
I'm writing an implemention of a scheme interpreter in C, and as people
familiar with that language know, it requires some stack manipulation.
Now to test this out I wrote a little program
#include stdio.h
int main() {
char * st1;
st1 = (void *)malloc(5000) + 5000;
asm(mov %0, %%esp : : r (st1));
fprintf(stderr, hello\n);
}
This program crashes silently and prints nothing under cygwin. However
this kind of thing works fine under Linux.
No, it doesn't 'work fine' under Linux. In fact it doesn't work at all,
on any platform. What you've written there is completely invalid and could
never work. Where on earth do you think main is going to return to after
you've discarded the old stack like that? The stack is for the compiler's
use, keep your hands off of it!
Now if I run it under gdb it says 0x610dfbb3 in cygwin1!_alloca () from
/usr/bin/cygwin1.dll
Which seems to indicate that the problem has something to do with alloca.
That would be a false inference unless you're using a version of the
cygwin dll with debugging information built in; if you aren't, that's just
the nearest exported symbol to the crash site but there could be several
functions in between.
Q1. Does cygwin and gcc have a real stack based alloca, or is it a fake
simulation?
Real.
Intuitively I assume that this kind of error would be caused
by the latter.
That just goes to show why 'intuition' is not a valid software development
methodology. http://catb.org/~esr/jargon/html/C/cargo-cult-programming.html
Q2. Why does this problem occur?
You just threw away the stack and jumped into space. What did you expect
to happen?
My vague guess
Again, let me urge you to reconsider your development methodology here.
Why make vague guesses, when there is a simple and plain fact of the
matter that you could easily determine by either debugging your application
or reading the source code?
is that something in the
bootstrap code for cygwin calls alloca, and because of the memory layout
of stack and heap, creating a heap based stack makes it free it
prematurely.
Q3. Shouldn't this be fixed in cygwin? While this is an unusual case, it
seems reasonable to me that a program should be able to create a new
stack if it wants to.
No, it's completely wrong-headed, insane and unreasonable. Your code is
100% bogus and should be taken out the back, lined up against a wall, and
machine-gunned.
Then the bleeding corpse should be hung, drawn and quartered.
Then burnt.
Then the smouldering rubble should be jumped up and down on.
By a hippo.
Q4. Is there any work around?
Write better code. Legal, valid, ANSI-compliant C would be good.
I'm guessing that if cygwin uses a fake
alloca, then a better implementation would fix it, but is there any way
to substitute another one without actually rebuilding cygwin.dll (which
I am loath to do).
Fortunately, there is absolutely nothing wrong with Cygwin's alloca; the
fault is entirely in the approach you have adopted for your implementation.
Do you mean the following:
[EMAIL PROTECTED] C++]$ make stack
cc stack.c -o stack
[EMAIL PROTECTED] C++]$ ./stack
Segmentation fault
I just can see that your code crashes there in both cygwin and linux.
I'm guessing that he tested it on a version of linux where the stdout
buffer got flushed before the crash happened, so he saw hello on the
output, saw the segv warning and pretended it didn't happen, and came to the
conclusion that his program 'works'.
cheers,
DaveK
--
Can't think of a witty .sigline today
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
