On Tue, 14 Sep 2004 08:02:10 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote:> On Mon, 13 Sep 2004 20:54:57 -0700 > Reid Spencer <reid at x10sys.com> wrote: > > > On the other hand, no one has submitted any Win32 patches yet, so first > > come first served :) > > > > Reid. > > Consider this a down payment :) The Win32 version of Memory.cpp attached.On further reflection, I think we need to abstract the operation of throwing a formatted OS error message. This is done in many places, and the Windows way of doing it differs substantially from Unix. Basically take the ThrowError function and turn it into Process::ThrowOSError or something like that.
Here are some more... and that takes care of the easy ones. Path I'll wait on until you finish updating it. Signals is a problem... It appears to be doing two tasks. First, it prints a stack trace when something like a seg fault occurs. Second, it makes sure a set of files and directories are deleted on an abnormal exit. The first is no problem. It won't even be necessary to fork off a separate program, so long as Microsoft-format symbol tables are present (and if there aren't... well... you'll just get a bunch of hexadecimal addresses). The other is a problem. It is not possible to delete open files on Windows, and the odds are these files will be open because... well... things crashed before there was a chance to clean things up. Even for the files which aren't open and so can be deleted, you wouldn't necessarily want to delete them at this point. After this handler executes, a dialog box pops up asking if you want to start the debugger. It might be a good idea to keep these files around as the program technically is still executing while it's being debugged. There is a Windows-centric solution to this: open the files with the delete-on-close flag. The implicit closing of all open files at process termination--normal or abnormal, or even post debugging--will trigger the deletion. How to take advantage of this is unfortunately far from obvious. -------------- next part -------------- A non-text attachment was scrubbed... Name: Memory.cpp Type: application/octet-stream Size: 1991 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040914/17ca4bf5/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: Process.cpp Type: application/octet-stream Size: 1467 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040914/17ca4bf5/attachment-0001.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: Program.cpp Type: application/octet-stream Size: 4663 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040914/17ca4bf5/attachment-0002.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: SysConfig.cpp Type: application/octet-stream Size: 1083 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040914/17ca4bf5/attachment-0003.obj>
Thanks, Jeff. I'll take a look at these later tonight and get them into CVS. Reid. On Tue, 2004-09-14 at 20:16, Jeff Cohen wrote:> Here are some more... and that takes care of the easy ones. > > Path I'll wait on until you finish updating it. > > Signals is a problem... It appears to be doing two tasks. First, it > prints a stack trace when something like a seg fault occurs. Second, it > makes sure a set of files and directories are deleted on an abnormal > exit. > > The first is no problem. It won't even be necessary to fork off a > separate program, so long as Microsoft-format symbol tables are present > (and if there aren't... well... you'll just get a bunch of hexadecimal > addresses). > > The other is a problem. It is not possible to delete open files on > Windows, and the odds are these files will be open because... well... > things crashed before there was a chance to clean things up. > > Even for the files which aren't open and so can be deleted, you wouldn't > necessarily want to delete them at this point. After this handler > executes, a dialog box pops up asking if you want to start the debugger. > It might be a good idea to keep these files around as the program > technically is still executing while it's being debugged. > > There is a Windows-centric solution to this: open the files with the > delete-on-close flag. The implicit closing of all open files at process > termination--normal or abnormal, or even post debugging--will trigger > the deletion. How to take advantage of this is unfortunately far from > obvious. > > ______________________________________________________________________ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040914/cc140ec3/attachment.sig>
Jeff/Henrik/Others, Thanks for contributing your patches. I really appreciate it. I've committed the changes that Jeff submitted for lib/System/Win32. I made some changes as I did. The departures are these: * I created a "Win32.h" header which includes our config header, windows.h and defines an inline ThrowError function that was duplicated in several modules. This is analagous to the Unix.h file in the lib/System/Unix directory. * I modified the SysConfig.cpp implementation to only get the page size once from the operating system and cache it in a static variable so that there isn't a huge penality every time this value is fetched. Henrik, I couldn't use your patches because they were malformed. Make sure that your email software doesn't mess with your attachments. It seems to be wrapping lines on you which messed up first character being + or -. Also, please always submit patches in unified diff format (diff -u). If it helps, send patches in winzip or tar.gz format which shouldn't get modified by your email software. From here on out, I'd appreciate it if you'd submit patches to the current CVS version. Just makes life much easier this end. Thanks to you both. Reid. On Tue, 2004-09-14 at 20:16, Jeff Cohen wrote:> Here are some more... and that takes care of the easy ones. > > Path I'll wait on until you finish updating it. > > Signals is a problem... It appears to be doing two tasks. First, it > prints a stack trace when something like a seg fault occurs. Second, it > makes sure a set of files and directories are deleted on an abnormal > exit. > > The first is no problem. It won't even be necessary to fork off a > separate program, so long as Microsoft-format symbol tables are present > (and if there aren't... well... you'll just get a bunch of hexadecimal > addresses). > > The other is a problem. It is not possible to delete open files on > Windows, and the odds are these files will be open because... well... > things crashed before there was a chance to clean things up. > > Even for the files which aren't open and so can be deleted, you wouldn't > necessarily want to delete them at this point. After this handler > executes, a dialog box pops up asking if you want to start the debugger. > It might be a good idea to keep these files around as the program > technically is still executing while it's being debugged. > > There is a Windows-centric solution to this: open the files with the > delete-on-close flag. The implicit closing of all open files at process > termination--normal or abnormal, or even post debugging--will trigger > the deletion. How to take advantage of this is unfortunately far from > obvious. > > ______________________________________________________________________ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040914/bf45c9ca/attachment.sig>