This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA] Major debugging breakage
- From: Christopher Faylor <cgf at redhat dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: law at redhat dot com, Neil Booth <neil at daikokuya dot demon dot co dot uk>, gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Fri, 11 Jan 2002 22:58:21 -0500
- Subject: Re: [RFA] Major debugging breakage
- References: <20020104012500.GA24783@redhat.com> <5248.1010113231@porcupine.cygnus.com> <20020104035114.GG11414@codesourcery.com> <20020110220820.GA30838@redhat.com> <20020110222608.GI21092@codesourcery.com>
On Thu, Jan 10, 2002 at 02:26:08PM -0800, Zack Weinberg wrote:
>On Thu, Jan 10, 2002 at 05:08:20PM -0500, Christopher Faylor wrote:
>>
>> Ok. We've admitted defeat on this one. Windows 9x wins. Sigh.
>>
>> So we have to turn off this feature for all Windows platforms since it
>> is possible that a gcc built on Windows NT (where mmap works fine) will
>> be run on Windows 98 (where it doesn't).
>
>Isn't there a way to determine at run time which version of Windows we
>are executing under?
Looking at the code again, I think it would be possible to do something
that would be minimally intrusive if you don't mind an
#ifdef _WIN32
#include <windows.h>
#endif
in that file.
I guess I didn't do it originally because it was basically an admission
of defeat. :-)
>> Does the below patch make sense? I qualified the BROKENness of mmap
>> because, as Zack suggested, it seems to work fine elsewhere and so we
>> don't want to slow down gcc's garbage collection.
>
>Assuming that we have to turn it off everywhere, (a) just re-#define
>MMAP_THRESHOLD to zero, and (b) shouldn't it be in xm-cygwin.h and
>xm-mingw32.h both? This isn't a target property.
You're right. AFAIK, mingw doesn't have mmap, though, so this isn't
an issue there.
>(Alternatively, put an #ifdef _WIN32 block in cppfiles.c. It already
>has plenty of #ifdeffage, more won't hurt much.)
That would simplify things.
I will work up an alternate runtime patch in the next couple of days,
if the above is ok with you.
-chris