2008/9/30 Neil Jerram <[EMAIL PROTECTED]>: > > Well, ideally we should have a solution that works automatically in > all circumstances...
FWIW, I'm actually thinking now that this stack calibration stuff is becoming way too tricky, in at least two ways. 1) The concept of the 'stack debug option being expressed in terms of some other "canonical" combination of OS, compiler and compiler optimization level. (I struggle to describe this clearly, here, and in comments in the code, and I'm sure I would struggle in the manual too - so that's a bad sign!) 2) The complexity that my latest patch adds to the Guile build process. And even with this complexity we still don't cover all the cases (notably cross compiling). Reviewing the history, we find that this work was prompted by people reporting Stack overflow errors when building Guile or when running make check [1]. We also find that such errors were _still_ reported by people who had some version of the calibration patch in place [2]. And there was a case, not yet understood, where the error was apparently caused by configuring without threads [3]. There was also a general discussion of how stack checking is implemented [4], which I think is sufficient to say that we should keep it basically in its current form (rather than implement an eval frame counter, say). [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg04401.html [2] http://article.gmane.org/gmane.lisp.guile.bugs/3881 [3] http://thread.gmane.org/gmane.lisp.guile.user/6628/focus=6629 [4] http://www.nabble.com/Re:-stack-overflow-td15467458.html Taking everything together, my thinking now is... - The problem we actually need to solve is getting a stack overflow while running make and/or make check, and there may be other ways of doing that than trying to pick the right number, and to interpret that number such that it has the same effect on all platforms. (For example, I think it would be fine if stack checking was disabled during make and make check, and (post build/install) when loading boot-9.scm. We don't need to guard against C stack overflow when running our own test suite, or when loading boot-9.scm, because overflow in those contexts isn't going to hurt anyone. The point of stack checking is to protect against runaway user/developer code (or Guile code being called from user/developer code).) - Based on [2], it sounds like there is part of this issue that we don't yet understand - i.e. not just the stack growing bigger than the default 20000 words. I plan to try and investigate [2] and [3] more, then hopefully propose something (simpler than my latest patch!). Regards, Neil
