Resending to the cygwin list this time...
On Fri, 2005-06-03 at 19:30, Christopher Faylor wrote:
> Wow! That's great! Thanks for doing this. It is much appreciated. This
> is something that I had been meaning to do and you did a better job than
> I would have. This truly deserves a gold star. I know that understanding
> the cygtls stuff could not have been easy.
>
> Can I get a gold star over here for this truly heroic effort?
*blush*
> I have checked in everything but the test suite stuff. I would like to
> see some changes there:
>
> 1) Use '.cc' rather than '.cpp' for the extension to be consistent with
> the rest of winsup.
Oops. All the other things I was trying to get right and that one
was staring me in the face. :-)
> 2) Use the same formatting that is used throughout cygwin for brace
> placement, etc.
Sure. I tried looking for the appropriate emacs settings for
the canonical cygwin style, but I can't find out how to get my
password for access to the cygwin-developers archive to see if
anyone has already answered that one. Another couple of good
things for the cygwin-developers FAQ or maybe a README.coding-style
in winsup could be:
* How do I access the cygwin-developers archives through
the Web interface?
* What parameters should I set in my source code editor
so it automatically does the proper indentation for the
canonicaly cygwin style?
Meanwhile, cygload isn't that large, so I just set c-basic-offset
to 2 and hand-tweaked the braces. I'll be submitting the revised
patch for cygload today.
> 3) Submit the new files as diffs against /dev/null so that I can apply
> like a normal patch.
Aha! I'd been wondering how that would look in a patch. That might
be a good one for the "contributing" page.
You may have noticed that I'm a compulsive documenter. If you
want to leave the effort of turning a brief E-mail reply into a
FAQ entry or README to me, I'll be happy to submit the patch. :-)
> Did you consider other ways of dealing with the need for space at the
> bottom of the stack?
That's a tricky one. The first thing I tried was to just declare
char padding[4096] as the first thing in main(), but that trashed
argv and argc and the context that mainCRTStartup() uses for
getting the return value from main(). Even the entry point hack I
used doesn't take care of *everything*: turn on the -v option
in cygload and you'll see that even the entry point comes in (IIRC)
64 or 100 bytes up the stack, depending on whether you're in MinGW
or MSVC.
If you just declare cygwin::padding as the first thing in
main function, it'll *work*, but you then you need to follow
it up with something like
std::vector<const char *> args(argv, argv+argc);
so argv gets backed up on the heap and won't get trashed
when cygwin initializes. (The actual strings of argv are
malloc'ed, at least in the MSVC crt0.c; I didn't check MinGW.)
> This has the downside of maybe causing more code disruption, though...
Yeah. My goal with cygload was to provide an example that could
be added to an existing tool with minimal redesign. If I were
doing something as thorough as "you have to redesign your main()
function", I'd also have it spawn a thread to run the main()
function, have the actual main thread just loop on nanosleep()
or one of the appropriate pthread functions so it can receive
signals, and then have the thread running main() pass the return value
back for proper cleanup at the end.
It might be worth creating an alternate version of cygload as
an example of that technique.
