public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* gold work on mingw/mingw64 support
@ 2010-12-30 18:19 Vladimir Simonov
  2010-12-30 18:24 ` Ralf Wildenhues
  2010-12-30 19:26 ` Ian Lance Taylor
  0 siblings, 2 replies; 19+ messages in thread
From: Vladimir Simonov @ 2010-12-30 18:19 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: binutils

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

Hi,

Attaching the patch which allows to build gold working
in mingw/mingw64 environment.

The patch's idea is to provide restricted emulation for
Linux-specific calls, like mremap, mremap, etc. And force
callers always to keep files in-memory.

Yes, this approach is a bit memory consuming but
IMO it is not a problem, especially for mingw64.
Really, for 32-bit Windows cygwin-based gold may be used.

It is a port of my patch against binutils 2.20.1 and
it was not tested deep. Original patch works
quite well - I saw only debug-info messing in very
large programs.

What do you think about this approach and the patch itself?

Thanks in advance
Vladimir Simonov


[-- Attachment #2: binutils-2.21-gold-migw.patch --]
[-- Type: text/plain, Size: 5831 bytes --]

diff -ruN binutils-2.21//gold/descriptors.cc ../i686-gcc-4.4.3-glibc-2.3.2-0.43/build/binutils-2.21/gold/descriptors.cc
--- binutils-2.21//gold/descriptors.cc	2010-07-14 14:38:59.000000000 +0400
+++ binutils-2.21/gold/descriptors.cc	2010-12-29 11:41:04.744856600 +0300
@@ -130,10 +130,12 @@
 	  // header file but not supported by the kernel.
 	  // Unfortunately there doesn't seem to be any obvious way to
 	  // detect that, as unknown flags passed to open are ignored.
+#ifndef __MINGW32__
 	  if (O_CLOEXEC == 0
 	      && parameters->options_valid()
 	      && parameters->options().has_plugins())
 	    fcntl(new_descriptor, F_SETFD, FD_CLOEXEC);
+#endif
 
 	  {
 	    Hold_optional_lock hl(this->lock_);
diff -ruN binutils-2.21//gold/fileread.cc ../i686-gcc-4.4.3-glibc-2.3.2-0.43/build/binutils-2.21/gold/fileread.cc
--- binutils-2.21//gold/fileread.cc	2010-10-12 19:30:24.000000000 +0400
+++ binutils-2.21/gold/fileread.cc	2010-12-29 11:41:04.994855000 +0300
@@ -26,7 +26,11 @@
 #include <cerrno>
 #include <fcntl.h>
 #include <unistd.h>
+#ifndef __MINGW32__
 #include <sys/mman.h>
+#else
+#include "mremap.h"
+#endif
 
 #ifdef HAVE_READV
 #include <sys/uio.h>
@@ -195,6 +199,7 @@
 {
   gold_assert(this->is_locked());
 
+#ifndef __MINGW32__
   if (!parameters->options_valid() || parameters->options().stats())
     {
       file_counts_initialize_lock.initialize();
@@ -204,6 +209,7 @@
       if (File_read::current_mapped_bytes > File_read::maximum_mapped_bytes)
 	File_read::maximum_mapped_bytes = File_read::current_mapped_bytes;
     }
+#endif
 
   this->mapped_bytes_ = 0;
 
@@ -414,7 +420,9 @@
     }
 
   File_read::View* v;
+#ifndef __MINGW32__
   if (byteshift != 0)
+#endif
     {
       unsigned char* p = new unsigned char[psize + byteshift];
       memset(p, 0, byteshift);
@@ -422,6 +430,7 @@
       v = new File_read::View(poff, psize, p, byteshift, cache,
                               View::DATA_ALLOCATED_ARRAY);
     }
+#ifndef __MINGW32__
   else
     {
       this->reopen_descriptor();
@@ -440,6 +449,7 @@
       v = new File_read::View(poff, psize, pbytes, 0, cache,
                               View::DATA_MMAPPED);
     }
+#endif
 
   this->add_view(v);
 
diff -ruN binutils-2.21//gold/incremental.cc ../i686-gcc-4.4.3-glibc-2.3.2-0.43/build/binutils-2.21/gold/incremental.cc
--- binutils-2.21//gold/incremental.cc	2010-10-15 02:10:22.000000000 +0400
+++ binutils-2.21/gold/incremental.cc	2010-12-29 11:41:04.776106400 +0300
@@ -117,12 +117,19 @@
 void
 vexplain_no_incremental(const char* format, va_list args)
 {
+#ifndef __MINGW32__
   char* buf = NULL;
   if (vasprintf(&buf, format, args) < 0)
     gold_nomem();
   gold_info(_("the link might take longer: "
               "cannot perform incremental link: %s"), buf);
   free(buf);
+#else
+  char buf[4096];
+  vsnprintf(buf, sizeof(buf), format, args);
+  gold_info(_("the link might take longer: "
+              "cannot perform incremental link: %s"), buf);
+#endif
 }
 
 void
diff -ruN binutils-2.21//gold/mremap.c ../i686-gcc-4.4.3-glibc-2.3.2-0.43/build/binutils-2.21/gold/mremap.c
--- binutils-2.21//gold/mremap.c	2009-03-28 08:22:30.000000000 +0300
+++ binutils-2.21/gold/mremap.c	2010-12-29 11:41:04.854230900 +0300
@@ -25,7 +25,14 @@
 
 #include <string.h>
 #include <sys/types.h>
+#ifndef __MINGW32__
 #include <sys/mman.h>
+#else
+#ifdef HAVE_STDLIB_H
+#include <stdlib.h>
+#endif
+#include "mremap.h"
+#endif
 
 /* This file implements mremap for systems which don't have it.  The
    gold code requires support for mmap.  However, there are systems
@@ -57,3 +64,23 @@
   (void) munmap (old_address, old_size);
   return ret;
 }
+
+void *
+mmap64 (void *__addr, size_t __len, int __prot ATTRIBUTE_UNUSED,
+       int __flags, int __fd, long long  __offset ATTRIBUTE_UNUSED)
+{
+  void *ret;
+  if (__addr || __fd != -1 || (__flags & MAP_SHARED))
+    return MAP_FAILED;
+  ret = malloc(__len);
+  if (!ret)
+    return MAP_FAILED;
+  return ret;  
+}
+
+int
+munmap (void *__addr, size_t __len ATTRIBUTE_UNUSED)
+{
+  free(__addr);
+  return 0;
+}
diff -ruN binutils-2.21//gold/mremap.h ../i686-gcc-4.4.3-glibc-2.3.2-0.43/build/binutils-2.21/gold/mremap.h
--- binutils-2.21//gold/mremap.h	1970-01-01 03:00:00.000000000 +0300
+++ binutils-2.21/gold/mremap.h	2010-12-29 11:41:04.869855800 +0300
@@ -0,0 +1,47 @@
+#ifndef GOLD_MREMAP_H
+#define GOLD_MREMAP_H
+
+#define PROT_READ 0x1
+#define PROT_WRITE 0x2
+#define PROT_EXEC 0x4
+#define PROT_NONE 0x0
+
+#define MAP_SHARED 0x01
+#define MAP_PRIVATE 0x02
+
+#define MAP_TYPE 0x0f
+
+#define MAP_FIXED 0x10
+
+#define MAP_FILE 0
+#define MAP_ANONYMOUS 0x20
+#define MAP_ANON MAP_ANONYMOUS
+#define MAP_32BIT 0x40
+
+#define MAP_GROWSDOWN 0x0100
+#define MAP_DENYWRITE 0x0800
+#define MAP_EXECUTABLE 0x1000
+#define MAP_LOCKED 0x2000
+#define MAP_NORESERVE 0x4000
+
+#define MREMAP_MAYMOVE 1
+
+#define MAP_FAILED ((void *) -1)
+
+#ifndef S_ISLNK
+#define S_ISLNK(x) (0)
+#endif
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+extern void *mmap64 (void *__addr, size_t __len, int __prot,
+                    int __flags, int __fd, long long __offset);
+#define mmap(p1, p2, p3, p4, p5, p6) mmap64(p1, p2, p3, p4, p5, p6)
+extern int munmap (void *__addr, size_t __len);
+extern void *mremap (void *, size_t, size_t, int, ...);
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* !defined(GOLD_MREMAP_H) */
diff -ruN binutils-2.21//gold/output.cc ../i686-gcc-4.4.3-glibc-2.3.2-0.43/build/binutils-2.21/gold/output.cc
--- binutils-2.21//gold/output.cc	2010-11-18 11:24:22.000000000 +0300
+++ binutils-2.21/gold/output.cc	2010-12-29 11:41:04.947980300 +0300
@@ -27,7 +27,11 @@
 #include <cerrno>
 #include <fcntl.h>
 #include <unistd.h>
+#ifndef __MINGW32__
 #include <sys/mman.h>
+#else
+#include "mremap.h"
+#endif
 #include <sys/stat.h>
 #include <algorithm>
 #include "libiberty.h"


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2010-12-30 18:19 gold work on mingw/mingw64 support Vladimir Simonov
@ 2010-12-30 18:24 ` Ralf Wildenhues
  2010-12-30 19:26 ` Ian Lance Taylor
  1 sibling, 0 replies; 19+ messages in thread
From: Ralf Wildenhues @ 2010-12-30 18:24 UTC (permalink / raw)
  To: Vladimir Simonov; +Cc: Ian Lance Taylor, binutils

Hello Vladimir,

* Vladimir Simonov wrote on Thu, Dec 30, 2010 at 06:47:55PM CET:
> The patch's idea is to provide restricted emulation for
> Linux-specific calls, like mremap, mremap, etc. And force
> callers always to keep files in-memory.

> What do you think about this approach and the patch itself?

As a by-stander, I would suggest using configure checks for headers and
functions which might or might not be present, and using #ifdef, if at
all needed, only or at least mostly with those platform-independent
defines set by the configure macros (HAVE_SYS_MMAN_H etc).

One could use gnulib modules to emulate some of the remaining missing
functionality (fcntl FDCLOEXEC, anon mmap).  That would not solve the
remaining mmap issues yet; for those one /could/ write a local gnulib
module, I suppose.

I can see that at least for the current goal each of these steps might
seem like overkill; I'm not sure whether or when they might pay off
sometime later.  Let's see what Ian thinks.

Cheers,
Ralf

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2010-12-30 18:19 gold work on mingw/mingw64 support Vladimir Simonov
  2010-12-30 18:24 ` Ralf Wildenhues
@ 2010-12-30 19:26 ` Ian Lance Taylor
  2011-01-04 17:02   ` Vladimir Simonov
  1 sibling, 1 reply; 19+ messages in thread
From: Ian Lance Taylor @ 2010-12-30 19:26 UTC (permalink / raw)
  To: Vladimir Simonov; +Cc: binutils

Vladimir Simonov <sv@sw.ru> writes:

> Attaching the patch which allows to build gold working
> in mingw/mingw64 environment.
>
> The patch's idea is to provide restricted emulation for
> Linux-specific calls, like mremap, mremap, etc. And force
> callers always to keep files in-memory.
>
> Yes, this approach is a bit memory consuming but
> IMO it is not a problem, especially for mingw64.
> Really, for 32-bit Windows cygwin-based gold may be used.
>
> It is a port of my patch against binutils 2.20.1 and
> it was not tested deep. Original patch works
> quite well - I saw only debug-info messing in very
> large programs.
>
> What do you think about this approach and the patch itself?

Thanks for sending the patch.  I definitely do not want to include a
patch which sprinkles #ifndef __MINGW32__ across the gold sources.  A
better way to handle this would be library routines which would only be
used, or not used, on mingw, with the configure script and Makefile
selecting the code to compile.


> @@ -195,6 +199,7 @@
>  {
>    gold_assert(this->is_locked());
>  
> +#ifndef __MINGW32__
>    if (!parameters->options_valid() || parameters->options().stats())
>      {
>        file_counts_initialize_lock.initialize();
> @@ -204,6 +209,7 @@
>        if (File_read::current_mapped_bytes > File_read::maximum_mapped_bytes)
>  	File_read::maximum_mapped_bytes = File_read::current_mapped_bytes;
>      }
> +#endif

Why #ifndef out this code?


> @@ -414,7 +420,9 @@
>      }
>  
>    File_read::View* v;
> +#ifndef __MINGW32__
>    if (byteshift != 0)
> +#endif
>      {
>        unsigned char* p = new unsigned char[psize + byteshift];
>        memset(p, 0, byteshift);
> @@ -422,6 +430,7 @@
>        v = new File_read::View(poff, psize, p, byteshift, cache,
>                                View::DATA_ALLOCATED_ARRAY);
>      }
> +#ifndef __MINGW32__
>    else
>      {
>        this->reopen_descriptor();
> @@ -440,6 +449,7 @@
>        v = new File_read::View(poff, psize, pbytes, 0, cache,
>                                View::DATA_MMAPPED);
>      }
> +#endif

I don't mind adjusting the code to use new/read instead of mmap, but it
would need to be done in a more clean fashion, such as by replacing mmap
as you did in output.cc.  This replacement should be done without
#ifndef __MINGW32__.


> diff -ruN binutils-2.21//gold/incremental.cc ../i686-gcc-4.4.3-glibc-2.3.2-0.43/build/binutils-2.21/gold/incremental.cc
> --- binutils-2.21//gold/incremental.cc	2010-10-15 02:10:22.000000000 +0400
> +++ binutils-2.21/gold/incremental.cc	2010-12-29 11:41:04.776106400 +0300
> @@ -117,12 +117,19 @@
>  void
>  vexplain_no_incremental(const char* format, va_list args)
>  {
> +#ifndef __MINGW32__
>    char* buf = NULL;
>    if (vasprintf(&buf, format, args) < 0)
>      gold_nomem();
>    gold_info(_("the link might take longer: "
>                "cannot perform incremental link: %s"), buf);
>    free(buf);
> +#else
> +  char buf[4096];
> +  vsnprintf(buf, sizeof(buf), format, args);
> +  gold_info(_("the link might take longer: "
> +              "cannot perform incremental link: %s"), buf);
> +#endif

Why is this necessary?  vasprintf is in libiberty.

Ian

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2010-12-30 19:26 ` Ian Lance Taylor
@ 2011-01-04 17:02   ` Vladimir Simonov
  2011-01-04 17:36     ` Ian Lance Taylor
  0 siblings, 1 reply; 19+ messages in thread
From: Vladimir Simonov @ 2011-01-04 17:02 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: binutils

[-- Attachment #1: Type: text/plain, Size: 4103 bytes --]

On 12/30/2010 10:25 PM, Ian Lance Taylor wrote:
> Vladimir Simonov<sv@sw.ru>  writes:
>
>> Attaching the patch which allows to build gold working
>> in mingw/mingw64 environment.
>>
>> The patch's idea is to provide restricted emulation for
>> Linux-specific calls, like mremap, mremap, etc. And force
>> callers always to keep files in-memory.
>>
>> Yes, this approach is a bit memory consuming but
>> IMO it is not a problem, especially for mingw64.
>> Really, for 32-bit Windows cygwin-based gold may be used.
>>
>> It is a port of my patch against binutils 2.20.1 and
>> it was not tested deep. Original patch works
>> quite well - I saw only debug-info messing in very
>> large programs.
>>
>> What do you think about this approach and the patch itself?
>
> Thanks for sending the patch.  I definitely do not want to include a
> patch which sprinkles #ifndef __MINGW32__ across the gold sources.  A
> better way to handle this would be library routines which would only be
> used, or not used, on mingw, with the configure script and Makefile
> selecting the code to compile.
>
>
>> @@ -195,6 +199,7 @@
>>   {
>>     gold_assert(this->is_locked());
>>
>> +#ifndef __MINGW32__
>>     if (!parameters->options_valid() || parameters->options().stats())
>>       {
>>         file_counts_initialize_lock.initialize();
>> @@ -204,6 +209,7 @@
>>         if (File_read::current_mapped_bytes>  File_read::maximum_mapped_bytes)
>>   	File_read::maximum_mapped_bytes = File_read::current_mapped_bytes;
>>       }
>> +#endif
>
> Why #ifndef out this code?
>
>
>> @@ -414,7 +420,9 @@
>>       }
>>
>>     File_read::View* v;
>> +#ifndef __MINGW32__
>>     if (byteshift != 0)
>> +#endif
>>       {
>>         unsigned char* p = new unsigned char[psize + byteshift];
>>         memset(p, 0, byteshift);
>> @@ -422,6 +430,7 @@
>>         v = new File_read::View(poff, psize, p, byteshift, cache,
>>                                 View::DATA_ALLOCATED_ARRAY);
>>       }
>> +#ifndef __MINGW32__
>>     else
>>       {
>>         this->reopen_descriptor();
>> @@ -440,6 +449,7 @@
>>         v = new File_read::View(poff, psize, pbytes, 0, cache,
>>                                 View::DATA_MMAPPED);
>>       }
>> +#endif
>
> I don't mind adjusting the code to use new/read instead of mmap, but it
> would need to be done in a more clean fashion, such as by replacing mmap
> as you did in output.cc.  This replacement should be done without
> #ifndef __MINGW32__.
>
>
>> diff -ruN binutils-2.21//gold/incremental.cc ../i686-gcc-4.4.3-glibc-2.3.2-0.43/build/binutils-2.21/gold/incremental.cc
>> --- binutils-2.21//gold/incremental.cc	2010-10-15 02:10:22.000000000 +0400
>> +++ binutils-2.21/gold/incremental.cc	2010-12-29 11:41:04.776106400 +0300
>> @@ -117,12 +117,19 @@
>>   void
>>   vexplain_no_incremental(const char* format, va_list args)
>>   {
>> +#ifndef __MINGW32__
>>     char* buf = NULL;
>>     if (vasprintf(&buf, format, args)<  0)
>>       gold_nomem();
>>     gold_info(_("the link might take longer: "
>>                 "cannot perform incremental link: %s"), buf);
>>     free(buf);
>> +#else
>> +  char buf[4096];
>> +  vsnprintf(buf, sizeof(buf), format, args);
>> +  gold_info(_("the link might take longer: "
>> +              "cannot perform incremental link: %s"), buf);
>> +#endif
>
> Why is this necessary?  vasprintf is in libiberty.
>
> Ian
>

Hi Ian,

Thank you for attention and good review.
Attaching new version which is a bit better, I hope.

I still trying to keep changes minimal and live without
additional libraries, configure and Makefile changes.

IMO mremap.c, pread.c, etc. are a kind of such library.
Analysis of target OS capabilities is overkill here, we
know in advance - mingw doesn't have mmap and most probably
won't have it.

If __MINGW32__ looks too OS specific it may be
replaced with HAVE_NO_MMAP, HAVE_NO_CLOEXEC defined
in config/mh-mingw. Really __MINGW32__ looks quite strange
in the middle of descriptors.cc but I don't know how to do it
better - fake function in mremap.h would be also strange,
new fcntl.c - the same...

Best regards
Vladimir Simonov

[-- Attachment #2: binutils-2.21-gold-mingw-2.patch --]
[-- Type: text/plain, Size: 6132 bytes --]

diff -ruN binutils-2.21.orig/config/mh-mingw binutils-2.21/config/mh-mingw
--- binutils-2.21.orig/config/mh-mingw	2008-11-27 20:22:09 +0300
+++ binutils-2.21/config/mh-mingw	2011-01-02 14:32:09 +0300
@@ -2,5 +2,6 @@
 # Vista (see PR33281 for details).
 BOOT_CFLAGS += -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format
 CFLAGS += -D__USE_MINGW_ACCESS
+CXXFLAGS += -D__USE_MINGW_ACCESS
 # Increase stack limit to same as Linux default.
 LDFLAGS += -Wl,--stack,8388608
diff -ruN binutils-2.21.orig/gold/descriptors.cc binutils-2.21/gold/descriptors.cc
--- binutils-2.21.orig/gold/descriptors.cc	2010-07-14 14:38:59 +0400
+++ binutils-2.21/gold/descriptors.cc	2011-01-03 16:26:42 +0300
@@ -130,10 +130,12 @@
 	  // header file but not supported by the kernel.
 	  // Unfortunately there doesn't seem to be any obvious way to
 	  // detect that, as unknown flags passed to open are ignored.
+#ifndef __MINGW32__
 	  if (O_CLOEXEC == 0
 	      && parameters->options_valid()
 	      && parameters->options().has_plugins())
 	    fcntl(new_descriptor, F_SETFD, FD_CLOEXEC);
+#endif
 
 	  {
 	    Hold_optional_lock hl(this->lock_);
diff -ruN binutils-2.21.orig/gold/fileread.cc binutils-2.21/gold/fileread.cc
--- binutils-2.21.orig/gold/fileread.cc	2010-10-12 19:30:24 +0400
+++ binutils-2.21/gold/fileread.cc	2011-01-01 21:23:41 +0300
@@ -26,13 +26,13 @@
 #include <cerrno>
 #include <fcntl.h>
 #include <unistd.h>
-#include <sys/mman.h>
 
 #ifdef HAVE_READV
 #include <sys/uio.h>
 #endif
 
 #include <sys/stat.h>
+#include "mremap.h"
 #include "filenames.h"
 
 #include "debug.h"
diff -ruN binutils-2.21.orig/gold/gold.h binutils-2.21/gold/gold.h
--- binutils-2.21.orig/gold/gold.h	2010-06-02 03:37:57 +0400
+++ binutils-2.21/gold/gold.h	2011-01-01 21:05:02 +0300
@@ -135,11 +135,6 @@
 extern "C" int ftruncate(int, off_t);
 #endif
 
-#ifndef HAVE_MREMAP
-#define MREMAP_MAYMOVE 1
-extern "C" void *mremap(void *, size_t, size_t, int, ...);
-#endif
-
 #ifndef HAVE_FFSLL
 extern "C" int ffsll(long long);
 #endif
diff -ruN binutils-2.21.orig/gold/mremap.c binutils-2.21/gold/mremap.c
--- binutils-2.21.orig/gold/mremap.c	2009-03-28 08:22:30 +0300
+++ binutils-2.21/gold/mremap.c	2011-01-03 16:37:09 +0300
@@ -25,7 +25,11 @@
 
 #include <string.h>
 #include <sys/types.h>
-#include <sys/mman.h>
+#ifdef HAVE_STDLIB_H
+#include <stdlib.h>
+#endif
+
+#include "mremap.h"
 
 /* This file implements mremap for systems which don't have it.  The
    gold code requires support for mmap.  However, there are systems
@@ -57,3 +61,42 @@
   (void) munmap (old_address, old_size);
   return ret;
 }
+
+#ifdef __MINGW32__
+
+extern ssize_t pread (int, void *, size_t, off_t);
+
+void *
+mmap64 (void *__addr, size_t __len, int __prot,
+       int __flags, int __fd, long long  __offset)
+{
+  void *ret;
+  ssize_t count;
+
+  if (__addr || (__fd != -1 && (__prot & PROT_WRITE))
+             || (__flags & MAP_SHARED))
+    return MAP_FAILED;
+  ret = malloc (__len);
+  if (!ret)
+    return MAP_FAILED;
+
+  if (__fd == -1)
+    return ret;
+
+  count = pread (__fd, ret, __len, __offset);
+  if ((size_t) count != __len)
+    {
+    free (ret);
+    return MAP_FAILED;
+    }
+
+  return ret;
+}
+
+int
+munmap (void *__addr, size_t __len ATTRIBUTE_UNUSED)
+{
+  free (__addr);
+  return 0;
+}
+#endif
diff -ruN binutils-2.21.orig/gold/mremap.h binutils-2.21/gold/mremap.h
--- binutils-2.21.orig/gold/mremap.h	1970-01-01 03:00:00 +0300
+++ binutils-2.21/gold/mremap.h	2011-01-03 16:13:08 +0300
@@ -0,0 +1,81 @@
+/* mremap.h -- mmap family functions prototypes for gold.  */
+
+/* Copyright 2009 Free Software Foundation, Inc.
+   Written by Ian Lance Taylor <iant@google.com>
+          and Vladimir Simonov <sv@sw.ru>
+
+   This file is part of gold.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston,
+   MA 02110-1301, USA.  */
+
+#ifndef GOLD_MREMAP_H
+#define GOLD_MREMAP_H
+
+#ifndef __MINGW32__
+#include <sys/mman.h>
+#endif
+
+#ifndef HAVE_MREMAP
+#define MREMAP_MAYMOVE 1
+#ifdef __cplusplus
+extern "C"
+#endif
+void *mremap(void *, size_t, size_t, int, ...);
+#endif /* HAVE_MREMAP */
+
+#ifdef __MINGW32__
+#define PROT_READ 0x1
+#define PROT_WRITE 0x2
+#define PROT_EXEC 0x4
+#define PROT_NONE 0x0
+
+#define MAP_SHARED 0x01
+#define MAP_PRIVATE 0x02
+
+#define MAP_TYPE 0x0f
+
+#define MAP_FIXED 0x10
+
+#define MAP_FILE 0
+#define MAP_ANONYMOUS 0x20
+#define MAP_ANON MAP_ANONYMOUS
+#define MAP_32BIT 0x40
+
+#define MAP_GROWSDOWN 0x0100
+#define MAP_DENYWRITE 0x0800
+#define MAP_EXECUTABLE 0x1000
+#define MAP_LOCKED 0x2000
+#define MAP_NORESERVE 0x4000
+
+#define MAP_FAILED ((void *) -1)
+
+#ifndef S_ISLNK
+#define S_ISLNK(x) (0)
+#endif
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+extern void *mmap64(void *__addr, size_t __len, int __prot,
+                    int __flags, int __fd, long long __offset);
+#define mmap(p1, p2, p3, p4, p5, p6) mmap64(p1, p2, p3, p4, p5, p6)
+extern int munmap(void *__addr, size_t __len);
+#ifdef __cplusplus
+}
+#endif
+#endif /* __MINGW32__ */
+
+#endif /* GOLD_MREMAP_H */
diff -ruN binutils-2.21.orig/gold/output.cc binutils-2.21/gold/output.cc
--- binutils-2.21.orig/gold/output.cc	2010-11-18 11:24:22 +0300
+++ binutils-2.21/gold/output.cc	2011-01-01 21:10:09 +0300
@@ -27,11 +27,11 @@
 #include <cerrno>
 #include <fcntl.h>
 #include <unistd.h>
-#include <sys/mman.h>
 #include <sys/stat.h>
 #include <algorithm>
 #include "libiberty.h"
 
+#include "mremap.h"
 #include "parameters.h"
 #include "object.h"
 #include "symtab.h"

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2011-01-04 17:02   ` Vladimir Simonov
@ 2011-01-04 17:36     ` Ian Lance Taylor
  2011-01-05 12:31       ` Vladimir Simonov
  0 siblings, 1 reply; 19+ messages in thread
From: Ian Lance Taylor @ 2011-01-04 17:36 UTC (permalink / raw)
  To: Vladimir Simonov; +Cc: binutils

Vladimir Simonov <sv@sw.ru> writes:

> IMO mremap.c, pread.c, etc. are a kind of such library.
> Analysis of target OS capabilities is overkill here, we
> know in advance - mingw doesn't have mmap and most probably
> won't have it.

Sure, but there are other systems that also don't have mmap.  We don't
want to test for all of them.

> If __MINGW32__ looks too OS specific it may be
> replaced with HAVE_NO_MMAP, HAVE_NO_CLOEXEC defined
> in config/mh-mingw. Really __MINGW32__ looks quite strange
> in the middle of descriptors.cc but I don't know how to do it
> better - fake function in mremap.h would be also strange,
> new fcntl.c - the same...

I'm complaining in part about the __MINGW32__ and in part about the
#ifdef.  Apart from ENABLE_THREADS, the only #ifdefs in gold are very
small ones at the top of a few .cc files.  Let's keep it that way.

Ian

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2011-01-04 17:36     ` Ian Lance Taylor
@ 2011-01-05 12:31       ` Vladimir Simonov
  2011-04-12 11:35         ` NightStrike
  2011-04-12 18:06         ` Ian Lance Taylor
  0 siblings, 2 replies; 19+ messages in thread
From: Vladimir Simonov @ 2011-01-05 12:31 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: binutils

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

On 01/04/2011 08:35 PM, Ian Lance Taylor wrote:
> Vladimir Simonov<sv@sw.ru>  writes:
>
>> IMO mremap.c, pread.c, etc. are a kind of such library.
>> Analysis of target OS capabilities is overkill here, we
>> know in advance - mingw doesn't have mmap and most probably
>> won't have it.
>
> Sure, but there are other systems that also don't have mmap.  We don't
> want to test for all of them.
>
>> If __MINGW32__ looks too OS specific it may be
>> replaced with HAVE_NO_MMAP, HAVE_NO_CLOEXEC defined
>> in config/mh-mingw. Really __MINGW32__ looks quite strange
>> in the middle of descriptors.cc but I don't know how to do it
>> better - fake function in mremap.h would be also strange,
>> new fcntl.c - the same...
>
> I'm complaining in part about the __MINGW32__ and in part about the
> #ifdef.  Apart from ENABLE_THREADS, the only #ifdefs in gold are very
> small ones at the top of a few .cc files.  Let's keep it that way.
>
> Ian
>

OK. Here is a version without __MINGW32__, with sys/mman.h and mmap
function presence detection and new mmap.h/mmap.c.
It is larger but should satisfy you requirements.
Could you comment?

Best regards
Vladimir Simonov

[-- Attachment #2: binutils-2.21-gold-mingw-3.patch --]
[-- Type: text/plain, Size: 9684 bytes --]

diff -ruN binutils-2.21.orig/config/mh-mingw binutils-2.21/config/mh-mingw
--- binutils-2.21.orig/config/mh-mingw	2008-11-27 20:22:09.000000000 +0300
+++ binutils-2.21/config/mh-mingw	2011-01-05 14:01:25.012653500 +0300
@@ -2,5 +2,6 @@
 # Vista (see PR33281 for details).
 BOOT_CFLAGS += -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format
 CFLAGS += -D__USE_MINGW_ACCESS
+CXXFLAGS += -D__USE_MINGW_ACCESS
 # Increase stack limit to same as Linux default.
 LDFLAGS += -Wl,--stack,8388608
diff -ruN binutils-2.21.orig/gold/config.in binutils-2.21/gold/config.in
--- binutils-2.21.orig/gold/config.in	2009-12-17 19:02:02.000000000 +0300
+++ binutils-2.21/gold/config.in	2011-01-05 12:50:30.000000000 +0300
@@ -87,6 +87,9 @@
 /* Define to 1 if you have the <memory.h> header file. */
 #undef HAVE_MEMORY_H
 
+/* Define to 1 if you have the `mmap' function. */
+#undef HAVE_MMAP
+
 /* Define to 1 if you have the `mremap' function. */
 #undef HAVE_MREMAP
 
@@ -120,6 +123,9 @@
 /* Define to 1 if you have the `sysconf' function. */
 #undef HAVE_SYSCONF
 
+/* Define to 1 if you have the <sys/mman.h> header file. */
+#undef HAVE_SYS_MMAN_H
+
 /* Define to 1 if you have the <sys/stat.h> header file. */
 #undef HAVE_SYS_STAT_H
 
diff -ruN binutils-2.21.orig/gold/configure binutils-2.21/gold/configure
--- binutils-2.21.orig/gold/configure	2010-11-23 16:50:32.000000000 +0300
+++ binutils-2.21/gold/configure	2011-01-05 12:50:23.368053200 +0300
@@ -6496,7 +6496,7 @@
 fi
 done
 
-for ac_func in pread ftruncate mremap ffsll
+for ac_func in pread ftruncate mremap ffsll mmap
 do :
   as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh`
 ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var"
@@ -6846,6 +6846,18 @@
 _ACEOF
 
 fi
+
+done
+
+for ac_header in sys/mman.h
+do :
+  ac_fn_cxx_check_header_mongrel "$LINENO" "sys/mman.h" "ac_cv_header_sys_mman_h" "$ac_includes_default"
+if test "x$ac_cv_header_sys_mman_h" = x""yes; then :
+  cat >>confdefs.h <<_ACEOF
+#define HAVE_SYS_MMAN_H 1
+_ACEOF
+
+fi
 
 done
 
diff -ruN binutils-2.21.orig/gold/configure.ac binutils-2.21/gold/configure.ac
--- binutils-2.21.orig/gold/configure.ac	2010-11-23 16:50:32.000000000 +0300
+++ binutils-2.21/gold/configure.ac	2011-01-05 12:48:45.181181600 +0300
@@ -393,7 +393,7 @@
 AC_SUBST(LFS_CFLAGS)
 
 AC_CHECK_FUNCS(chsize)
-AC_REPLACE_FUNCS(pread ftruncate mremap ffsll)
+AC_REPLACE_FUNCS(pread ftruncate mremap ffsll mmap)
 
 # Link in zlib if we can.  This allows us to write compressed sections.
 AC_SEARCH_LIBS(zlibVersion, z, [AC_CHECK_HEADERS(zlib.h)])
@@ -410,6 +410,7 @@
 AC_CHECK_HEADERS(tr1/unordered_set tr1/unordered_map)
 AC_CHECK_HEADERS(ext/hash_map ext/hash_set)
 AC_CHECK_HEADERS(byteswap.h)
+AC_CHECK_HEADERS(sys/mman.h)
 AC_CHECK_FUNCS(mallinfo posix_fallocate readv sysconf times)
 AC_CHECK_DECLS([basename, ffs, asprintf, vasprintf, snprintf, vsnprintf, strverscmp, strndup, memmem])
 
diff -ruN binutils-2.21.orig/gold/descriptors.cc binutils-2.21/gold/descriptors.cc
--- binutils-2.21.orig/gold/descriptors.cc	2010-07-14 14:38:59.000000000 +0400
+++ binutils-2.21/gold/descriptors.cc	2011-01-05 14:38:46.982679800 +0300
@@ -44,6 +44,17 @@
 #define O_CLOEXEC 0
 #endif
 
+namespace
+{
+void
+set_close_on_exec(int fd)
+{
+#ifdef F_SETFD
+  fcntl(fd, F_SETFD, FD_CLOEXEC);
+#endif
+}
+}
+
 namespace gold
 {
 
@@ -133,7 +144,7 @@
 	  if (O_CLOEXEC == 0
 	      && parameters->options_valid()
 	      && parameters->options().has_plugins())
-	    fcntl(new_descriptor, F_SETFD, FD_CLOEXEC);
+	    set_close_on_exec(new_descriptor);
 
 	  {
 	    Hold_optional_lock hl(this->lock_);
diff -ruN binutils-2.21.orig/gold/fileread.cc binutils-2.21/gold/fileread.cc
--- binutils-2.21.orig/gold/fileread.cc	2010-10-12 19:30:24.000000000 +0400
+++ binutils-2.21/gold/fileread.cc	2011-01-05 13:03:18.894339800 +0300
@@ -26,13 +26,13 @@
 #include <cerrno>
 #include <fcntl.h>
 #include <unistd.h>
-#include <sys/mman.h>
 
 #ifdef HAVE_READV
 #include <sys/uio.h>
 #endif
 
 #include <sys/stat.h>
+#include "mmap.h"
 #include "filenames.h"
 
 #include "debug.h"
diff -ruN binutils-2.21.orig/gold/mmap.c binutils-2.21/gold/mmap.c
--- binutils-2.21.orig/gold/mmap.c	1970-01-01 03:00:00.000000000 +0300
+++ binutils-2.21/gold/mmap.c	2011-01-05 14:26:55.862231000 +0300
@@ -0,0 +1,69 @@
+/* mmap.c -- version of mmap for gold.  */
+
+/* Copyright 2009 Free Software Foundation, Inc.
+   Written by Vladimir Simonov <sv@sw.ru>.
+
+   This file is part of gold.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston,
+   MA 02110-1301, USA.  */
+
+#include "config.h"
+#include "ansidecl.h"
+
+#include <string.h>
+#include <sys/types.h>
+#ifdef HAVE_STDLIB_H
+#include <stdlib.h>
+#endif
+
+#include "mmap.h"
+
+extern ssize_t pread (int, void *, size_t, off_t);
+
+void *
+mmap (void *__addr, size_t __len, int __prot,
+       int __flags, int __fd, long long  __offset)
+{
+  void *ret;
+  ssize_t count;
+
+  if (__addr || (__fd != -1 && (__prot & PROT_WRITE))
+             || (__flags & MAP_SHARED))
+    return MAP_FAILED;
+
+  ret = malloc (__len);
+  if (!ret)
+    return MAP_FAILED;
+
+  if (__fd == -1)
+    return ret;
+
+  count = pread (__fd, ret, __len, __offset);
+  if ((size_t) count != __len)
+    {
+    free (ret);
+    return MAP_FAILED;
+    }
+
+  return ret;
+}
+
+int
+munmap (void *__addr, size_t __len ATTRIBUTE_UNUSED)
+{
+  free (__addr);
+  return 0;
+}
diff -ruN binutils-2.21.orig/gold/mmap.h binutils-2.21/gold/mmap.h
--- binutils-2.21.orig/gold/mmap.h	1970-01-01 03:00:00.000000000 +0300
+++ binutils-2.21/gold/mmap.h	2011-01-05 14:25:50.362650200 +0300
@@ -0,0 +1,62 @@
+/* mmap.h -- mmap family functions prototypes for gold.  */
+
+/* Copyright 2009 Free Software Foundation, Inc.
+   Written by Vladimir Simonov <sv@sw.ru>
+
+   This file is part of gold.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston,
+   MA 02110-1301, USA.  */
+
+#ifndef GOLD_MMAP_H
+#define GOLD_MMAP_H
+
+#ifdef HAVE_SYS_MMAN_H
+
+#include <sys/mman.h>
+
+/* Some BSD systems still use MAP_ANON instead of MAP_ANONYMOUS.  */
+
+#ifndef MAP_ANONYMOUS
+# define MAP_ANONYMOUS MAP_ANON
+#endif
+
+#else
+
+#define PROT_READ 0x1
+#define PROT_WRITE 0x2
+
+#define MAP_SHARED 0x01
+#define MAP_PRIVATE 0x02
+
+#define MAP_ANONYMOUS 0x20
+
+#define MAP_FAILED ((void *) -1)
+#endif /* HAVE_SYS_MMAN_H */
+
+#ifndef HAVE_MMAP
+#ifdef __cplusplus
+extern "C" {
+#endif
+extern void *mmap (void *__addr, size_t __len, int __prot,
+                    int __flags, int __fd, long long __offset);
+extern int munmap (void *__addr, size_t __len);
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* HAVE_MMAP */
+
+#endif /* GOLD_MMAP_H */
diff -ruN binutils-2.21.orig/gold/mremap.c binutils-2.21/gold/mremap.c
--- binutils-2.21.orig/gold/mremap.c	2009-03-28 08:22:30.000000000 +0300
+++ binutils-2.21/gold/mremap.c	2011-01-05 13:42:40.629224600 +0300
@@ -25,7 +25,7 @@
 
 #include <string.h>
 #include <sys/types.h>
-#include <sys/mman.h>
+#include "mmap.h"
 
 /* This file implements mremap for systems which don't have it.  The
    gold code requires support for mmap.  However, there are systems
@@ -34,12 +34,6 @@
    gold.  In particular, we assume that the MREMAP_MAYMOVE flag is
    set.  */
 
-/* Some BSD systems still use MAP_ANON instead of MAP_ANONYMOUS.  */
-
-#ifndef MAP_ANONYMOUS
-# define MAP_ANONYMOUS MAP_ANON
-#endif
-
 extern void *mremap (void *, size_t, size_t, int, ...);
 
 void *
diff -ruN binutils-2.21.orig/gold/output.cc binutils-2.21/gold/output.cc
--- binutils-2.21.orig/gold/output.cc	2010-11-18 11:24:22.000000000 +0300
+++ binutils-2.21/gold/output.cc	2011-01-05 13:44:47.659661600 +0300
@@ -27,11 +27,11 @@
 #include <cerrno>
 #include <fcntl.h>
 #include <unistd.h>
-#include <sys/mman.h>
 #include <sys/stat.h>
 #include <algorithm>
 #include "libiberty.h"
 
+#include "mmap.h"
 #include "parameters.h"
 #include "object.h"
 #include "symtab.h"
@@ -40,11 +40,6 @@
 #include "descriptors.h"
 #include "output.h"
 
-// Some BSD systems still use MAP_ANON instead of MAP_ANONYMOUS
-#ifndef MAP_ANONYMOUS
-# define MAP_ANONYMOUS  MAP_ANON
-#endif
-
 #ifndef HAVE_POSIX_FALLOCATE
 // A dummy, non general, version of posix_fallocate.  Here we just set
 // the file size and hope that there is enough disk space.  FIXME: We
@@ -57,6 +52,10 @@
 }
 #endif // !defined(HAVE_POSIX_FALLOCATE)
 
+#ifndef S_ISLNK
+# define S_ISLNK(x) (0)
+#endif
+
 namespace gold
 {
 

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2011-01-05 12:31       ` Vladimir Simonov
@ 2011-04-12 11:35         ` NightStrike
  2011-04-12 18:06         ` Ian Lance Taylor
  1 sibling, 0 replies; 19+ messages in thread
From: NightStrike @ 2011-04-12 11:35 UTC (permalink / raw)
  To: Vladimir Simonov; +Cc: Ian Lance Taylor, binutils

Ping

On Wed, Jan 5, 2011 at 7:17 AM, Vladimir Simonov <sv@sw.ru> wrote:
> On 01/04/2011 08:35 PM, Ian Lance Taylor wrote:
>>
>> Vladimir Simonov<sv@sw.ru>  writes:
>>
>>> IMO mremap.c, pread.c, etc. are a kind of such library.
>>> Analysis of target OS capabilities is overkill here, we
>>> know in advance - mingw doesn't have mmap and most probably
>>> won't have it.
>>
>> Sure, but there are other systems that also don't have mmap.  We don't
>> want to test for all of them.
>>
>>> If __MINGW32__ looks too OS specific it may be
>>> replaced with HAVE_NO_MMAP, HAVE_NO_CLOEXEC defined
>>> in config/mh-mingw. Really __MINGW32__ looks quite strange
>>> in the middle of descriptors.cc but I don't know how to do it
>>> better - fake function in mremap.h would be also strange,
>>> new fcntl.c - the same...
>>
>> I'm complaining in part about the __MINGW32__ and in part about the
>> #ifdef.  Apart from ENABLE_THREADS, the only #ifdefs in gold are very
>> small ones at the top of a few .cc files.  Let's keep it that way.
>>
>> Ian
>>
>
> OK. Here is a version without __MINGW32__, with sys/mman.h and mmap
> function presence detection and new mmap.h/mmap.c.
> It is larger but should satisfy you requirements.
> Could you comment?
>
> Best regards
> Vladimir Simonov
>

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2011-01-05 12:31       ` Vladimir Simonov
  2011-04-12 11:35         ` NightStrike
@ 2011-04-12 18:06         ` Ian Lance Taylor
  2011-04-13  9:46           ` Vladimir Simonov
  1 sibling, 1 reply; 19+ messages in thread
From: Ian Lance Taylor @ 2011-04-12 18:06 UTC (permalink / raw)
  To: Vladimir Simonov; +Cc: binutils

[-- Attachment #1: Type: text/plain, Size: 2862 bytes --]

Vladimir Simonov <sv@sw.ru> writes:

> On 01/04/2011 08:35 PM, Ian Lance Taylor wrote:
>> Vladimir Simonov<sv@sw.ru>  writes:
>>
>>> IMO mremap.c, pread.c, etc. are a kind of such library.
>>> Analysis of target OS capabilities is overkill here, we
>>> know in advance - mingw doesn't have mmap and most probably
>>> won't have it.
>>
>> Sure, but there are other systems that also don't have mmap.  We don't
>> want to test for all of them.
>>
>>> If __MINGW32__ looks too OS specific it may be
>>> replaced with HAVE_NO_MMAP, HAVE_NO_CLOEXEC defined
>>> in config/mh-mingw. Really __MINGW32__ looks quite strange
>>> in the middle of descriptors.cc but I don't know how to do it
>>> better - fake function in mremap.h would be also strange,
>>> new fcntl.c - the same...
>>
>> I'm complaining in part about the __MINGW32__ and in part about the
>> #ifdef.  Apart from ENABLE_THREADS, the only #ifdefs in gold are very
>> small ones at the top of a few .cc files.  Let's keep it that way.
>>
>> Ian
>>
>
> OK. Here is a version without __MINGW32__, with sys/mman.h and mmap
> function presence detection and new mmap.h/mmap.c.
> It is larger but should satisfy you requirements.
> Could you comment?

Thanks.

I decided to go a different route.  It seems that mmap could in general
fail for a file which can nevertheless be read.  So I decided to go
ahead and change gold to handle the case of mmap failing.  This then
turns the mingw32 code into a matter of supporting systems which don't
provide mmap by providing a stub mmap which always fails.

I committed the appended patch.  Let me know if you find problems with
it.  This patch also cleans up mremap a bit even on systems which
provide mmap.

Ian


2011-04-12  Ian Lance Taylor  <iant@google.com>

	* configure.ac: Check for sys/mman.h and mmap.  Check for mremap
	with MREMAP_MAYMOVE.
	* output.h (class Output_file): Add map_is_allocated_ field.
	* output.cc: Only #include <sys/mman.h> if it exists.  If mmap is
	not available, provide stubs.  If mremap is not available, #define
	it to gold_mremap.
	(MREMAP_MAYMOVE): Define if not defined.
	(Output_file::Output_file): Initialize map_is_allocated_.
	(Output_file::resize): Check map_is_allocated_.
	(Output_file::map_anonymous): If mmap fails, use malloc.
	(Output_file::unmap): Don't do anything for an anonymous map.
	* fileread.cc: Only #include <sys/mman.h> if it exists.  If mmap
	is not available, provide stubs.
	(File_read::View::~View): Use free rather than delete[].
	(File_read::make_view): Use malloc rather than new[].  If mmap
	fails, use malloc.
	(File_read::find_or_make_view): Use malloc rather than new[].
	* gold.h: Remove HAVE_REMAP code.
	* mremap.c: #include <errno.h>.  Only #include <sys/mman.h> if it
	exists.  Rename mremap to gold_mremap.  If mmap is not available
	don't do anything.
	* configure, config.in: Rebuild.



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 13250 bytes --]

Index: output.h
===================================================================
RCS file: /cvs/src/src/gold/output.h,v
retrieving revision 1.119
diff -p -u -r1.119 output.h
--- output.h	12 Apr 2011 00:44:48 -0000	1.119
+++ output.h	12 Apr 2011 18:01:49 -0000
@@ -1,6 +1,6 @@
 // output.h -- manage the output file for gold   -*- C++ -*-
 
-// Copyright 2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
+// Copyright 2006, 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
 // Written by Ian Lance Taylor <iant@google.com>.
 
 // This file is part of gold.
@@ -4221,6 +4221,8 @@ class Output_file
   unsigned char* base_;
   // True iff base_ points to a memory buffer rather than an output file.
   bool map_is_anonymous_;
+  // True if base_ was allocated using new rather than mmap.
+  bool map_is_allocated_;
   // True if this is a temporary file which should not be output.
   bool is_temporary_;
 };
Index: configure.ac
===================================================================
RCS file: /cvs/src/src/gold/configure.ac,v
retrieving revision 1.61
diff -p -u -r1.61 configure.ac
--- configure.ac	2 Mar 2011 14:51:42 -0000	1.61
+++ configure.ac	12 Apr 2011 18:01:49 -0000
@@ -393,8 +393,22 @@ dnl host dependent.  If build == host, w
 LFS_CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
 AC_SUBST(LFS_CFLAGS)
 
-AC_CHECK_FUNCS(chsize)
-AC_REPLACE_FUNCS(pread ftruncate mremap ffsll)
+AC_CHECK_HEADERS(sys/mman.h)
+AC_CHECK_FUNCS(chsize mmap)
+AC_REPLACE_FUNCS(pread ftruncate ffsll)
+
+AC_CACHE_CHECK([mremap with MREMAP_MAYMOVE], [gold_cv_lib_mremap_maymove],
+[AC_LINK_IFELSE([
+AC_LANG_PROGRAM([[
+#include <sys/mman.h>
+void f() { mremap (0, 0, 0, MREMAP_MAYMOVE); }
+]])], [gold_cv_lib_mremap_maymove=yes], [gold_cv_lib_mremap_maymove=no])])
+if test "$gold_cv_lib_mremap_maymove" = "yes"; then
+  AC_DEFINE(HAVE_MREMAP, 1,
+    [Define to 1 if you have the mremap function with MREMAP_MAYMOVE support])
+else
+  AC_LIBOBJ(mremap)
+fi
 
 # Link in zlib if we can.  This allows us to write compressed sections.
 AC_SEARCH_LIBS(zlibVersion, z, [AC_CHECK_HEADERS(zlib.h)])
Index: gold.h
===================================================================
RCS file: /cvs/src/src/gold/gold.h,v
retrieving revision 1.45
diff -p -u -r1.45 gold.h
--- gold.h	14 Dec 2010 19:03:29 -0000	1.45
+++ gold.h	12 Apr 2011 18:01:49 -0000
@@ -1,6 +1,6 @@
 // gold.h -- general definitions for gold   -*- C++ -*-
 
-// Copyright 2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
+// Copyright 2006, 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
 // Written by Ian Lance Taylor <iant@google.com>.
 
 // This file is part of gold.
@@ -135,11 +135,6 @@ extern "C" ssize_t pread(int, void*, siz
 extern "C" int ftruncate(int, off_t);
 #endif
 
-#ifndef HAVE_MREMAP
-#define MREMAP_MAYMOVE 1
-extern "C" void *mremap(void *, size_t, size_t, int, ...);
-#endif
-
 #ifndef HAVE_FFSLL
 extern "C" int ffsll(long long);
 #endif
Index: output.cc
===================================================================
RCS file: /cvs/src/src/gold/output.cc,v
retrieving revision 1.141
diff -p -u -r1.141 output.cc
--- output.cc	12 Apr 2011 00:44:48 -0000	1.141
+++ output.cc	12 Apr 2011 18:01:49 -0000
@@ -1,6 +1,6 @@
 // output.cc -- manage the output file for gold
 
-// Copyright 2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
+// Copyright 2006, 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
 // Written by Ian Lance Taylor <iant@google.com>.
 
 // This file is part of gold.
@@ -27,9 +27,13 @@
 #include <cerrno>
 #include <fcntl.h>
 #include <unistd.h>
-#include <sys/mman.h>
 #include <sys/stat.h>
 #include <algorithm>
+
+#ifdef HAVE_SYS_MMAN_H
+#include <sys/mman.h>
+#endif
+
 #include "libiberty.h"
 
 #include "parameters.h"
@@ -40,11 +44,71 @@
 #include "descriptors.h"
 #include "output.h"
 
+// For systems without mmap support.
+#ifndef HAVE_MMAP
+# define mmap gold_mmap
+# define munmap gold_munmap
+# define mremap gold_mremap
+# ifndef MAP_FAILED
+#  define MAP_FAILED (reinterpret_cast<void*>(-1))
+# endif
+# ifndef PROT_READ
+#  define PROT_READ 0
+# endif
+# ifndef PROT_WRITE
+#  define PROT_WRITE 0
+# endif
+# ifndef MAP_PRIVATE
+#  define MAP_PRIVATE 0
+# endif
+# ifndef MAP_ANONYMOUS
+#  define MAP_ANONYMOUS 0
+# endif
+# ifndef MAP_SHARED
+#  define MAP_SHARED 0
+# endif
+
+# ifndef ENOSYS
+#  define ENOSYS EINVAL
+# endif
+
+static void *
+gold_mmap(void *, size_t, int, int, int, off_t)
+{
+  errno = ENOSYS;
+  return MAP_FAILED;
+}
+
+static int
+gold_munmap(void *, size_t)
+{
+  errno = ENOSYS;
+  return -1;
+}
+
+static void *
+gold_mremap(void *, size_t, size_t, int)
+{
+  errno = ENOSYS;
+  return MAP_FAILED;
+}
+
+#endif
+
+#if defined(HAVE_MMAP) && !defined(HAVE_MREMAP)
+# define mremap gold_mremap
+extern "C" void *gold_mremap(void *, size_t, size_t, int);
+#endif
+
 // Some BSD systems still use MAP_ANON instead of MAP_ANONYMOUS
 #ifndef MAP_ANONYMOUS
 # define MAP_ANONYMOUS  MAP_ANON
 #endif
 
+#ifndef MREMAP_MAYMOVE
+# define MREMAP_MAYMOVE 1
+#endif
+
 #ifndef HAVE_POSIX_FALLOCATE
 // A dummy, non general, version of posix_fallocate.  Here we just set
 // the file size and hope that there is enough disk space.  FIXME: We
@@ -4415,6 +4479,7 @@ Output_file::Output_file(const char* nam
     file_size_(0),
     base_(NULL),
     map_is_anonymous_(false),
+    map_is_allocated_(false),
     is_temporary_(false)
 {
 }
@@ -4522,10 +4587,23 @@ Output_file::resize(off_t file_size)
   // to unmap to flush to the file, then remap after growing the file.
   if (this->map_is_anonymous_)
     {
-      void* base = ::mremap(this->base_, this->file_size_, file_size,
-                            MREMAP_MAYMOVE);
-      if (base == MAP_FAILED)
-        gold_fatal(_("%s: mremap: %s"), this->name_, strerror(errno));
+      void* base;
+      if (!this->map_is_allocated_)
+	{
+	  base = ::mremap(this->base_, this->file_size_, file_size,
+			  MREMAP_MAYMOVE);
+	  if (base == MAP_FAILED)
+	    gold_fatal(_("%s: mremap: %s"), this->name_, strerror(errno));
+	}
+      else
+	{
+	  base = realloc(this->base_, file_size);
+	  if (base == NULL)
+	    gold_nomem();
+	  if (file_size > this->file_size_)
+	    memset(static_cast<char*>(base) + this->file_size_, 0,
+		   file_size - this->file_size_);
+	}
       this->base_ = static_cast<unsigned char*>(base);
       this->file_size_ = file_size;
     }
@@ -4546,13 +4624,17 @@ Output_file::map_anonymous()
 {
   void* base = ::mmap(NULL, this->file_size_, PROT_READ | PROT_WRITE,
 		      MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
-  if (base != MAP_FAILED)
+  if (base == MAP_FAILED)
     {
-      this->map_is_anonymous_ = true;
-      this->base_ = static_cast<unsigned char*>(base);
-      return true;
+      base = malloc(this->file_size_);
+      if (base == NULL)
+	return false;
+      memset(base, 0, this->file_size_);
+      this->map_is_allocated_ = true;
     }
-  return false;
+  this->base_ = static_cast<unsigned char*>(base);
+  this->map_is_anonymous_ = true;
+  return true;
 }
 
 // Map the file into memory.  Return whether the mapping succeeded.
@@ -4624,8 +4706,16 @@ Output_file::map()
 void
 Output_file::unmap()
 {
-  if (::munmap(this->base_, this->file_size_) < 0)
-    gold_error(_("%s: munmap: %s"), this->name_, strerror(errno));
+  if (this->map_is_anonymous_)
+    {
+      // We've already written out the data, so there is no reason to
+      // waste time unmapping or freeing the memory.
+    }
+  else
+    {
+      if (::munmap(this->base_, this->file_size_) < 0)
+	gold_error(_("%s: munmap: %s"), this->name_, strerror(errno));
+    }
   this->base_ = NULL;
 }
 
Index: fileread.cc
===================================================================
RCS file: /cvs/src/src/gold/fileread.cc,v
retrieving revision 1.72
diff -p -u -r1.72 fileread.cc
--- fileread.cc	12 Apr 2011 00:44:47 -0000	1.72
+++ fileread.cc	12 Apr 2011 18:01:49 -0000
@@ -27,7 +27,10 @@
 #include <climits>
 #include <fcntl.h>
 #include <unistd.h>
+
+#ifdef HAVE_SYS_MMAN_H
 #include <sys/mman.h>
+#endif
 
 #ifdef HAVE_READV
 #include <sys/uio.h>
@@ -46,6 +49,40 @@
 #include "gold-threads.h"
 #include "fileread.h"
 
+// For systems without mmap support.
+#ifndef HAVE_MMAP
+# define mmap gold_mmap
+# define munmap gold_munmap
+# ifndef MAP_FAILED
+#  define MAP_FAILED (reinterpret_cast<void*>(-1))
+# endif
+# ifndef PROT_READ
+#  define PROT_READ 0
+# endif
+# ifndef MAP_PRIVATE
+#  define MAP_PRIVATE 0
+# endif
+
+# ifndef ENOSYS
+#  define ENOSYS EINVAL
+# endif
+
+static void *
+gold_mmap(void *, size_t, int, int, int, off_t)
+{
+  errno = ENOSYS;
+  return MAP_FAILED;
+}
+
+static int
+gold_munmap(void *, size_t)
+{
+  errno = ENOSYS;
+  return -1;
+}
+
+#endif
+
 #ifndef HAVE_READV
 struct iovec { void* iov_base; size_t iov_len; };
 ssize_t
@@ -96,7 +133,7 @@ File_read::View::~View()
   switch (this->data_ownership_)
     {
     case DATA_ALLOCATED_ARRAY:
-      delete[] this->data_;
+      free(const_cast<unsigned char*>(this->data_));
       break;
     case DATA_MMAPPED:
       if (::munmap(const_cast<unsigned char*>(this->data_), this->size_) != 0)
@@ -440,34 +477,40 @@ File_read::make_view(off_t start, sectio
       gold_assert(psize >= size);
     }
 
-  File_read::View* v;
+  void* p;
+  View::Data_ownership ownership;
   if (byteshift != 0)
     {
-      unsigned char* p = new unsigned char[psize + byteshift];
+      p = malloc(psize + byteshift);
+      if (p == NULL)
+	gold_nomem();
       memset(p, 0, byteshift);
-      this->do_read(poff, psize, p + byteshift);
-      v = new File_read::View(poff, psize, p, byteshift, cache,
-                              View::DATA_ALLOCATED_ARRAY);
+      this->do_read(poff, psize, static_cast<unsigned char*>(p) + byteshift);
+      ownership = View::DATA_ALLOCATED_ARRAY;
     }
   else
     {
       this->reopen_descriptor();
-      void* p = ::mmap(NULL, psize, PROT_READ, MAP_PRIVATE,
-                       this->descriptor_, poff);
-      if (p == MAP_FAILED)
-	gold_fatal(_("%s: mmap offset %lld size %lld failed: %s"),
-		   this->filename().c_str(),
-		   static_cast<long long>(poff),
-		   static_cast<long long>(psize),
-		   strerror(errno));
-
-      this->mapped_bytes_ += psize;
-
-      const unsigned char* pbytes = static_cast<const unsigned char*>(p);
-      v = new File_read::View(poff, psize, pbytes, 0, cache,
-                              View::DATA_MMAPPED);
+      p = ::mmap(NULL, psize, PROT_READ, MAP_PRIVATE, this->descriptor_, poff);
+      if (p != MAP_FAILED)
+	{
+	  ownership = View::DATA_MMAPPED;
+	  this->mapped_bytes_ += psize;
+	}
+      else
+	{
+	  p = malloc(psize);
+	  if (p == NULL)
+	    gold_nomem();
+	  this->do_read(poff, psize, p);
+	  ownership = View::DATA_ALLOCATED_ARRAY;
+	}
     }
 
+  const unsigned char* pbytes = static_cast<const unsigned char*>(p);
+  File_read::View* v = new File_read::View(poff, psize, pbytes, byteshift,
+					   cache, ownership);
+
   this->add_view(v);
 
   return v;
@@ -525,7 +568,10 @@ File_read::find_or_make_view(off_t offse
     {
       gold_assert(aligned);
 
-      unsigned char* pbytes = new unsigned char[v->size() + byteshift];
+      unsigned char* pbytes;
+      pbytes = static_cast<unsigned char*>(malloc(v->size() + byteshift));
+      if (pbytes == NULL)
+	gold_nomem();
       memset(pbytes, 0, byteshift);
       memcpy(pbytes + byteshift, v->data() + v->byteshift(), v->size());
 
Index: mremap.c
===================================================================
RCS file: /cvs/src/src/gold/mremap.c,v
retrieving revision 1.2
diff -p -u -r1.2 mremap.c
--- mremap.c	28 Mar 2009 05:22:30 -0000	1.2
+++ mremap.c	12 Apr 2011 18:01:49 -0000
@@ -1,6 +1,6 @@
 /* mremap.c -- version of mremap for gold.  */
 
-/* Copyright 2009 Free Software Foundation, Inc.
+/* Copyright 2009, 2011 Free Software Foundation, Inc.
    Written by Ian Lance Taylor <iant@google.com>.
 
    This file is part of gold.
@@ -23,9 +23,17 @@
 #include "config.h"
 #include "ansidecl.h"
 
+#include <errno.h>
 #include <string.h>
 #include <sys/types.h>
+
+#ifdef HAVE_SYS_MMAN_H
 #include <sys/mman.h>
+#endif
+
+extern void *gold_mremap (void *, size_t, size_t, int);
+
+#ifdef HAVE_MMAP
 
 /* This file implements mremap for systems which don't have it.  The
    gold code requires support for mmap.  However, there are systems
@@ -40,11 +48,9 @@
 # define MAP_ANONYMOUS MAP_ANON
 #endif
 
-extern void *mremap (void *, size_t, size_t, int, ...);
-
 void *
-mremap (void *old_address, size_t old_size, size_t new_size,
-	int flags ATTRIBUTE_UNUSED, ...)
+gold_mremap (void *old_address, size_t old_size, size_t new_size,
+	     int flags ATTRIBUTE_UNUSED)
 {
   void *ret;
 
@@ -57,3 +63,25 @@ mremap (void *old_address, size_t old_si
   (void) munmap (old_address, old_size);
   return ret;
 }
+
+#else /* !defined(HAVE_MMAP) */
+
+#ifndef MAP_FAILED
+#define MAP_FAILED ((void *) -1)
+#endif
+
+#ifndef ENOSYS
+#define ENOSYS EINVAL
+#endif
+
+void *
+gold_mremap (void *old_address ATTRIBUTE_UNUSED,
+	     size_t old_size ATTRIBUTE_UNUSED,
+	     size_t new_size ATTRIBUTE_UNUSED,
+	     int flags ATTRIBUTE_UNUSED)
+{
+  errno = ENOSYS;
+  return MAP_FAILED;
+}
+
+#endif /* !defined(HAVE_MMAP) */

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2011-04-12 18:06         ` Ian Lance Taylor
@ 2011-04-13  9:46           ` Vladimir Simonov
  2011-04-13 14:25             ` Ian Lance Taylor
  2011-04-18 15:49             ` Vladimir Simonov
  0 siblings, 2 replies; 19+ messages in thread
From: Vladimir Simonov @ 2011-04-13  9:46 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: binutils

On 04/12/2011 10:06 PM, Ian Lance Taylor wrote:
> Vladimir Simonov<sv@sw.ru>  writes:
>
>> On 01/04/2011 08:35 PM, Ian Lance Taylor wrote:
>>> Vladimir Simonov<sv@sw.ru>   writes:
>>>
>>>> IMO mremap.c, pread.c, etc. are a kind of such library.
>>>> Analysis of target OS capabilities is overkill here, we
>>>> know in advance - mingw doesn't have mmap and most probably
>>>> won't have it.
>>>
>>> Sure, but there are other systems that also don't have mmap.  We don't
>>> want to test for all of them.
>>>
>>>> If __MINGW32__ looks too OS specific it may be
>>>> replaced with HAVE_NO_MMAP, HAVE_NO_CLOEXEC defined
>>>> in config/mh-mingw. Really __MINGW32__ looks quite strange
>>>> in the middle of descriptors.cc but I don't know how to do it
>>>> better - fake function in mremap.h would be also strange,
>>>> new fcntl.c - the same...
>>>
>>> I'm complaining in part about the __MINGW32__ and in part about the
>>> #ifdef.  Apart from ENABLE_THREADS, the only #ifdefs in gold are very
>>> small ones at the top of a few .cc files.  Let's keep it that way.
>>>
>>> Ian
>>>
>>
>> OK. Here is a version without __MINGW32__, with sys/mman.h and mmap
>> function presence detection and new mmap.h/mmap.c.
>> It is larger but should satisfy you requirements.
>> Could you comment?
>
> Thanks.
>
> I decided to go a different route.  It seems that mmap could in general
> fail for a file which can nevertheless be read.  So I decided to go
> ahead and change gold to handle the case of mmap failing.  This then
> turns the mingw32 code into a matter of supporting systems which don't
> provide mmap by providing a stub mmap which always fails.
>
> I committed the appended patch.  Let me know if you find problems with
> it.  This patch also cleans up mremap a bit even on systems which
> provide mmap.
>
> Ian
>

Thank you. I'll check the patch in couple days and report.

The only I can say from the first glance - chunk from top-level
config/mh-mingw about CXXFLAGS += -D__USE_MINGW_ACCESS is missed.
It is below.
Cause gold is the only c++ program in binutils
I see no reasons against it.

Best regards
Vladimir

--- binutils-2.21.orig/config/mh-mingw	2008-11-27 20:22:09.000000000 +0300
+++ binutils-2.21/config/mh-mingw	2011-01-05 14:01:25.012653500 +0300
@@ -2,5 +2,6 @@
  # Vista (see PR33281 for details).
  BOOT_CFLAGS += -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format
  CFLAGS += -D__USE_MINGW_ACCESS
+CXXFLAGS += -D__USE_MINGW_ACCESS
  # Increase stack limit to same as Linux default.
  LDFLAGS += -Wl,--stack,8388608

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2011-04-13  9:46           ` Vladimir Simonov
@ 2011-04-13 14:25             ` Ian Lance Taylor
  2011-04-13 16:23               ` Vladimir Simonov
  2011-04-18 15:49             ` Vladimir Simonov
  1 sibling, 1 reply; 19+ messages in thread
From: Ian Lance Taylor @ 2011-04-13 14:25 UTC (permalink / raw)
  To: Vladimir Simonov; +Cc: binutils

Vladimir Simonov <sv@sw.ru> writes:

> The only I can say from the first glance - chunk from top-level
> config/mh-mingw about CXXFLAGS += -D__USE_MINGW_ACCESS is missed.
> It is below.
> Cause gold is the only c++ program in binutils
> I see no reasons against it.

Why is it necessary?  What difference does it make?  Note that gold
never calls access().

Ian

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2011-04-13 14:25             ` Ian Lance Taylor
@ 2011-04-13 16:23               ` Vladimir Simonov
  2011-04-13 17:28                 ` Ian Lance Taylor
  0 siblings, 1 reply; 19+ messages in thread
From: Vladimir Simonov @ 2011-04-13 16:23 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: binutils

On 04/13/2011 06:24 PM, Ian Lance Taylor wrote:
> Vladimir Simonov<sv@sw.ru>  writes:
>
>> The only I can say from the first glance - chunk from top-level
>> config/mh-mingw about CXXFLAGS += -D__USE_MINGW_ACCESS is missed.
>> It is below.
>> Cause gold is the only c++ program in binutils
>> I see no reasons against it.
>
> Why is it necessary?  What difference does it make?  Note that gold
> never calls access().
>
> Ian
>
Yes, it is not "the must", but it is defined for C in config/mh-mingw.
Why not define it for C++ for symmetry...

Vladimir

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2011-04-13 16:23               ` Vladimir Simonov
@ 2011-04-13 17:28                 ` Ian Lance Taylor
  0 siblings, 0 replies; 19+ messages in thread
From: Ian Lance Taylor @ 2011-04-13 17:28 UTC (permalink / raw)
  To: Vladimir Simonov; +Cc: binutils

Vladimir Simonov <sv@sw.ru> writes:

> On 04/13/2011 06:24 PM, Ian Lance Taylor wrote:
>> Vladimir Simonov<sv@sw.ru>  writes:
>>
>>> The only I can say from the first glance - chunk from top-level
>>> config/mh-mingw about CXXFLAGS += -D__USE_MINGW_ACCESS is missed.
>>> It is below.
>>> Cause gold is the only c++ program in binutils
>>> I see no reasons against it.
>>
>> Why is it necessary?  What difference does it make?  Note that gold
>> never calls access().
>>
>> Ian
>>
> Yes, it is not "the must", but it is defined for C in config/mh-mingw.
> Why not define it for C++ for symmetry...

I will leave that up to Nick and Alan.

Ian

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2011-04-13  9:46           ` Vladimir Simonov
  2011-04-13 14:25             ` Ian Lance Taylor
@ 2011-04-18 15:49             ` Vladimir Simonov
  2011-04-19 17:13               ` Vladimir Simonov
  2011-04-22 23:21               ` Ian Lance Taylor
  1 sibling, 2 replies; 19+ messages in thread
From: Vladimir Simonov @ 2011-04-18 15:49 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: binutils

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

On 04/13/2011 01:25 PM, Vladimir Simonov wrote:
> On 04/12/2011 10:06 PM, Ian Lance Taylor wrote:
>> I decided to go a different route. It seems that mmap could in general
>> fail for a file which can nevertheless be read. So I decided to go
>> ahead and change gold to handle the case of mmap failing. This then
>> turns the mingw32 code into a matter of supporting systems which don't
>> provide mmap by providing a stub mmap which always fails.
>>
>> I committed the appended patch. Let me know if you find problems with
>> it. This patch also cleans up mremap a bit even on systems which
>> provide mmap.
>>
>> Ian
>>
>
> Thank you. I'll check the patch in couple days and report.

Sorry for delay.
I've downloaded binutils-2.21.51
[binutils]$ grep 201104 binutils-2.21.51/ -r
binutils-2.21.51/bfd/version.h:#define BFD_VERSION_DATE 20110416
It contains your changes related to bool map_is_allocated_;

It is still having the problems I've mentioned earlier(in my patches):
build/binutils-2.21.51/gold/descriptors.cc:136: error: 'F_SETFD' was not declared in this 
scope
build/binutils-2.21.51/gold/descriptors.cc:136: error: 'fcntl' was not declared in this scope
build/binutils-2.21.51/gold/output.cc:4552: error: 'S_ISLNK' was not declared in this scope

Chunks fixing the issues are attached.

I'll let you know about new gold work in a day or so.

Best regards
Vladimir Simonov

[-- Attachment #2: binutils-2.21.51-gold-fcntl.patch --]
[-- Type: text/x-patch, Size: 1050 bytes --]

diff -ruN binutils-2.21.orig/gold/descriptors.cc binutils-2.21/gold/descriptors.cc
--- binutils-2.21.orig/gold/descriptors.cc	2010-07-14 14:38:59.000000000 +0400
+++ binutils-2.21/gold/descriptors.cc	2011-01-05 14:38:46.982679800 +0300
@@ -44,6 +44,17 @@
 #define O_CLOEXEC 0
 #endif
 
+namespace
+{
+void
+set_close_on_exec(int fd)
+{
+#ifdef F_SETFD
+  fcntl(fd, F_SETFD, FD_CLOEXEC);
+#endif
+}
+}
+
 namespace gold
 {
 
@@ -133,7 +144,7 @@
 	  if (O_CLOEXEC == 0
 	      && parameters->options_valid()
 	      && parameters->options().has_plugins())
-	    fcntl(new_descriptor, F_SETFD, FD_CLOEXEC);
+	    set_close_on_exec(new_descriptor);
 
 	  {
 	    Hold_optional_lock hl(this->lock_);
diff -ruN binutils-2.21.orig/gold/output.cc binutils-2.21/gold/output.cc
--- binutils-2.21.orig/gold/output.cc	2010-11-18 11:24:22.000000000 +0300
+++ binutils-2.21/gold/output.cc	2011-01-05 13:44:47.659661600 +0300
@@ -57,6 +52,10 @@
 }
 #endif // !defined(HAVE_POSIX_FALLOCATE)
 
+#ifndef S_ISLNK
+# define S_ISLNK(x) (0)
+#endif
+
 namespace gold
 {
 

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2011-04-18 15:49             ` Vladimir Simonov
@ 2011-04-19 17:13               ` Vladimir Simonov
  2011-04-19 17:33                 ` Ian Lance Taylor
  2011-04-22 23:21               ` Ian Lance Taylor
  1 sibling, 1 reply; 19+ messages in thread
From: Vladimir Simonov @ 2011-04-19 17:13 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: binutils, nightstrike

On 04/18/2011 07:28 PM, Vladimir Simonov wrote:
> On 04/13/2011 01:25 PM, Vladimir Simonov wrote:
>> On 04/12/2011 10:06 PM, Ian Lance Taylor wrote:
>>> I decided to go a different route. It seems that mmap could in general
>>> fail for a file which can nevertheless be read. So I decided to go
>>> ahead and change gold to handle the case of mmap failing. This then
>>> turns the mingw32 code into a matter of supporting systems which don't
>>> provide mmap by providing a stub mmap which always fails.
>>>
>>> I committed the appended patch. Let me know if you find problems with
>>> it. This patch also cleans up mremap a bit even on systems which
>>> provide mmap.
>>>
>>> Ian
>>>
>>
>> Thank you. I'll check the patch in couple days and report.
>
> Sorry for delay.
> I've downloaded binutils-2.21.51
> [binutils]$ grep 201104 binutils-2.21.51/ -r
> binutils-2.21.51/bfd/version.h:#define BFD_VERSION_DATE 20110416
> It contains your changes related to bool map_is_allocated_;
>
> It is still having the problems I've mentioned earlier(in my patches):
> build/binutils-2.21.51/gold/descriptors.cc:136: error: 'F_SETFD' was not
> declared in this scope
> build/binutils-2.21.51/gold/descriptors.cc:136: error: 'fcntl' was not
> declared in this scope
> build/binutils-2.21.51/gold/output.cc:4552: error: 'S_ISLNK' was not
> declared in this scope
>
> Chunks fixing the issues are attached.
>
> I'll let you know about new gold work in a day or so.

Hi all,

I confirm that binutils-2.21.51-201104 with patch fixing "fcntl"
and "S_ISLNK" works fine for me on mingw64.

Ian, what do you think about the rest of issues?
Do you think they should be fixed on mingw side?

Best regards
Vladimir Simonov

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2011-04-19 17:13               ` Vladimir Simonov
@ 2011-04-19 17:33                 ` Ian Lance Taylor
  0 siblings, 0 replies; 19+ messages in thread
From: Ian Lance Taylor @ 2011-04-19 17:33 UTC (permalink / raw)
  To: Vladimir Simonov; +Cc: binutils, nightstrike

Vladimir Simonov <sv@sw.ru> writes:

> I confirm that binutils-2.21.51-201104 with patch fixing "fcntl"
> and "S_ISLNK" works fine for me on mingw64.
>
> Ian, what do you think about the rest of issues?
> Do you think they should be fixed on mingw side?

No, something like your patch is reasonable.  I will try to get to it
shortly.

Ian

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2011-04-18 15:49             ` Vladimir Simonov
  2011-04-19 17:13               ` Vladimir Simonov
@ 2011-04-22 23:21               ` Ian Lance Taylor
  2011-06-30  8:18                 ` Vladimir Simonov
  1 sibling, 1 reply; 19+ messages in thread
From: Ian Lance Taylor @ 2011-04-22 23:21 UTC (permalink / raw)
  To: Vladimir Simonov; +Cc: binutils

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

Vladimir Simonov <sv@sw.ru> writes:

> It is still having the problems I've mentioned earlier(in my patches):
> build/binutils-2.21.51/gold/descriptors.cc:136: error: 'F_SETFD' was
> not declared in this scope
> build/binutils-2.21.51/gold/descriptors.cc:136: error: 'fcntl' was not declared in this scope
> build/binutils-2.21.51/gold/output.cc:4552: error: 'S_ISLNK' was not declared in this scope
>
> Chunks fixing the issues are attached.

Committed in slightly different form as follows.

Thanks.

Ian


2011-04-22  Vladimir Simonov  <sv@sw.ru>

	* descriptors.cc (set_close_on_exec): New function.
	(Descriptors::open): Use set_close_on_exec.
	* output.cc (S_ISLNK): Define if not defined.



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 1894 bytes --]

Index: descriptors.cc
===================================================================
RCS file: /cvs/src/src/gold/descriptors.cc,v
retrieving revision 1.9
diff -u -p -r1.9 descriptors.cc
--- descriptors.cc	14 Jul 2010 10:38:59 -0000	1.9
+++ descriptors.cc	22 Apr 2011 23:19:51 -0000
@@ -1,6 +1,6 @@
 // descriptors.cc -- manage file descriptors for gold
 
-// Copyright 2008, 2009 Free Software Foundation, Inc.
+// Copyright 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
 // Written by Ian Lance Taylor <iant@google.com>.
 
 // This file is part of gold.
@@ -34,15 +34,24 @@
 #include "descriptors.h"
 #include "binary-io.h"
 
+// O_CLOEXEC is only available on newer systems.
+#ifndef O_CLOEXEC
+#define O_CLOEXEC 0
+#endif
+
 // Very old systems may not define FD_CLOEXEC.
 #ifndef FD_CLOEXEC
 #define FD_CLOEXEC 1
 #endif
 
-// O_CLOEXEC is only available on newer systems.
-#ifndef O_CLOEXEC
-#define O_CLOEXEC 0
+static inline void
+set_close_on_exec(int fd)
+{
+// Mingw does not define F_SETFD.
+#ifdef F_SETFD
+  fcntl(fd, F_SETFD, FD_CLOEXEC);
 #endif
+}
 
 namespace gold
 {
@@ -133,7 +142,7 @@ Descriptors::open(int descriptor, const 
 	  if (O_CLOEXEC == 0
 	      && parameters->options_valid()
 	      && parameters->options().has_plugins())
-	    fcntl(new_descriptor, F_SETFD, FD_CLOEXEC);
+	    set_close_on_exec(new_descriptor);
 
 	  {
 	    Hold_optional_lock hl(this->lock_);
Index: output.cc
===================================================================
RCS file: /cvs/src/src/gold/output.cc,v
retrieving revision 1.142
diff -u -p -r1.142 output.cc
--- output.cc	12 Apr 2011 18:06:16 -0000	1.142
+++ output.cc	22 Apr 2011 23:19:52 -0000
@@ -121,6 +121,11 @@ posix_fallocate(int o, off_t offset, off
 }
 #endif // !defined(HAVE_POSIX_FALLOCATE)
 
+// Mingw does not have S_ISLNK.
+#ifndef S_ISLNK
+# define S_ISLNK(mode) 0
+#endif
+
 namespace gold
 {
 

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2011-04-22 23:21               ` Ian Lance Taylor
@ 2011-06-30  8:18                 ` Vladimir Simonov
  2011-06-30 15:48                   ` Ian Lance Taylor
  0 siblings, 1 reply; 19+ messages in thread
From: Vladimir Simonov @ 2011-06-30  8:18 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: binutils

On 04/23/2011 03:20 AM, Ian Lance Taylor wrote:
> Vladimir Simonov<sv@sw.ru>  writes:
>
>> It is still having the problems I've mentioned earlier(in my patches):
>> build/binutils-2.21.51/gold/descriptors.cc:136: error: 'F_SETFD' was
>> not declared in this scope
>> build/binutils-2.21.51/gold/descriptors.cc:136: error: 'fcntl' was not declared in this scope
>> build/binutils-2.21.51/gold/output.cc:4552: error: 'S_ISLNK' was not declared in this scope
>>
>> Chunks fixing the issues are attached.
>
> Committed in slightly different form as follows.
>
> Thanks.
>
> Ian
>

Hi Ian,

Sorry for disturb you, but I don't see the patch about F_SETFD
and core "mmap" patch in binutils 2.21.1.

Is it possible to push them into 2.21.1 branch (may be they go to
2.21.2 if it is planned)?

Thank you
Vladimir Simonov

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2011-06-30  8:18                 ` Vladimir Simonov
@ 2011-06-30 15:48                   ` Ian Lance Taylor
  2011-07-01  6:42                     ` Vladimir Simonov
  0 siblings, 1 reply; 19+ messages in thread
From: Ian Lance Taylor @ 2011-06-30 15:48 UTC (permalink / raw)
  To: Vladimir Simonov; +Cc: binutils

Vladimir Simonov <sv@sw.ru> writes:

> Sorry for disturb you, but I don't see the patch about F_SETFD
> and core "mmap" patch in binutils 2.21.1.
>
> Is it possible to push them into 2.21.1 branch (may be they go to
> 2.21.2 if it is planned)?

I didn't put the patch in the 2.21 branch because I wasn't absolutely
certain it was safe.  It's very unlikely that there will be a 2.21.2
release--I don't think binutils has ever done a N.N.2 release.  Sorry.

Ian

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: gold work on mingw/mingw64 support
  2011-06-30 15:48                   ` Ian Lance Taylor
@ 2011-07-01  6:42                     ` Vladimir Simonov
  0 siblings, 0 replies; 19+ messages in thread
From: Vladimir Simonov @ 2011-07-01  6:42 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: binutils

On 06/30/2011 07:48 PM, Ian Lance Taylor wrote:
> Vladimir Simonov<sv@sw.ru>  writes:
>
>> Sorry for disturb you, but I don't see the patch about F_SETFD
>> and core "mmap" patch in binutils 2.21.1.
>>
>> Is it possible to push them into 2.21.1 branch (may be they go to
>> 2.21.2 if it is planned)?
>
> I didn't put the patch in the 2.21 branch because I wasn't absolutely
> certain it was safe.  It's very unlikely that there will be a 2.21.2
> release--I don't think binutils has ever done a N.N.2 release.  Sorry.
>
> Ian
>

OK. No problem - the changes are in the cvs head and it is
stable enough, so it may be used if necessary.

Best regards
Vladimir

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2011-07-01  6:42 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-12-30 18:19 gold work on mingw/mingw64 support Vladimir Simonov
2010-12-30 18:24 ` Ralf Wildenhues
2010-12-30 19:26 ` Ian Lance Taylor
2011-01-04 17:02   ` Vladimir Simonov
2011-01-04 17:36     ` Ian Lance Taylor
2011-01-05 12:31       ` Vladimir Simonov
2011-04-12 11:35         ` NightStrike
2011-04-12 18:06         ` Ian Lance Taylor
2011-04-13  9:46           ` Vladimir Simonov
2011-04-13 14:25             ` Ian Lance Taylor
2011-04-13 16:23               ` Vladimir Simonov
2011-04-13 17:28                 ` Ian Lance Taylor
2011-04-18 15:49             ` Vladimir Simonov
2011-04-19 17:13               ` Vladimir Simonov
2011-04-19 17:33                 ` Ian Lance Taylor
2011-04-22 23:21               ` Ian Lance Taylor
2011-06-30  8:18                 ` Vladimir Simonov
2011-06-30 15:48                   ` Ian Lance Taylor
2011-07-01  6:42                     ` Vladimir Simonov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).