ftp.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-apps/2001/09/21/03:03:50

Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <3BAAE652.7050302@ece.gatech.edu>
Date: Fri, 21 Sep 2001 03:03:46 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713
X-Accept-Language: en-us
MIME-Version: 1.0
To: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
CC: cygwin-apps AT cygwin DOT com
Subject: Re: binutils patch [Was: Re: ncurses announcement - trial run]
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF08F1A3 AT itdomain002 DOT itdomain DOT net DOT au> <3BA958FB DOT 7060401 AT ece DOT gatech DOT edu> <20010919230018 DOT A26967 AT redhat DOT com> <3BAAE5C6 DOT 6030007 AT ece DOT gatech DOT edu>

This is a multi-part message in MIME format.
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Here are the other two patches, recently submitted to binutils@.


Content-Type: text/plain;
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;

2001-09-21  Charles Wilson  <cwilson AT ece DOT gatech DOT edu>

	* emultempl/pe.em(pe_data_import_dll): Make static.
	(pe_get_data_import_dll_name): New accessor function.
	* pe-dll.c(pe_create_import_fixup): call 
	pe_get_data_import_dll_name() from pe.em, instead of
	directly accessing pe_data_import_dll variable from pe.em.

Content-Type: text/plain;
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;

2001-09-21  Charles Wilson  <cwilson AT ece DOT gatech DOT edu>

	* ld.texinfo(enable-auto-import): clarify 
	the explanation.

Content-Type: text/plain;
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;

Index: ld/pe-dll.c
RCS file: /cvs/src/src/ld/pe-dll.c,v
retrieving revision 1.30
diff -u -r1.30  old/ld/pe-dll.c new/ld/pe-dll.c
--- old/ld/pe-dll.c	2001/09/19 05:33:33	1.30
+++ new/ld/pe-dll.c	2001/09/21 06:09:49
@@ -123,6 +123,9 @@
 static void
 add_bfd_to_link PARAMS ((bfd *, const char *, struct bfd_link_info *));
+extern char *
+pe_get_data_import_dll_name PARAMS(( ));  /* Defined in emultempl/pe.em.  */
 /* For emultempl/pe.em.  */
 def_file * pe_def_file = 0;
@@ -2065,10 +2068,9 @@
-    extern char * pe_data_import_dll;  /* Defined in emultempl/pe.em.  */
-    bfd *b = make_import_fixup_entry (name, fixup_name, pe_data_import_dll,
-				      output_bfd);
+    bfd *b = make_import_fixup_entry (name, fixup_name,
+                                      pe_get_data_import_dll_name(), 
+                                      output_bfd);
     add_bfd_to_link (b, b->filename, &link_info);
Index: ld/emultempl/pe.em
RCS file: /cvs/src/src/ld/emultempl/pe.em,v
retrieving revision 1.52
diff -u -r1.52  old/ld/emultempl/pe.em new/ld/emultempl/pe.em
--- old/ld/emultempl/pe.em	2001/09/18 10:10:21	1.52
+++ new/ld/emultempl/pe.em	2001/09/21 06:09:51
@@ -153,6 +153,7 @@
 static char *pe_implib_filename = NULL;
 static int pe_enable_auto_image_base = 0;
 static char *pe_dll_search_prefix = NULL;
+static char *pe_data_import_dll = NULL;
 extern const char *output_filename;
@@ -879,7 +880,32 @@
   return 1;
-char *pe_data_import_dll;
+/* Previously, pe-dll.c directly accessed pe_data_import_dll,
+ * which was only defined if DLL_SUPPORT.  This cause a build
+ * failure on certain targets. At least this function will
+ * exist regardless of whether DLL_SUPPORT is defined or not.
+ *
+ * However, it's still a kludge.  pe-dll.c shouldn't directly
+ * call any functions other than the gld_${EMULATION_NAME}_* 
+ * Nick suggests the following method:
+ *   I still feel however, that there ought to be a better 
+ *   way to solve this problem.  My suggestion is that the 
+ *   definition of DLL_SUPPORT ought to be set in ld/configure.tgt 
+ *   rather than ld/emultemp/pe.em and then tested in ld/pe-dll.c 
+ *   before it uses variables that are only defined in pe.em.
+ * However, I don't understand this.  ld/configure.tgt sets SHELL
+ * variables, not #define variables.  You'd need #define variables
+ * to #ifdef out the offending sections of code from pe-dll.c
+ */
+char *
+pe_get_data_import_dll_name ()
+  return pe_data_import_dll;
+  return "unknown";
 static void
 pe_find_data_imports ()

Content-Type: text/plain;
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;

Index: ld.texinfo
RCS file: /cvs/src/src/ld/ld.texinfo,v
retrieving revision 1.49
diff -u -r1.49 ld.texinfo
--- ld.texinfo	2001/09/12 15:58:10	1.49
+++ ld.texinfo	2001/09/21 06:42:08
@@ -1738,9 +1738,15 @@
 ultimately given by the sum of two constants (Win32 import tables only 
 allow one).  Instances where this may occur include accesses to member 
 fields of struct variables imported from a DLL, as well as using a 
-constant index into an array variable imported from a DLL.  There are
-several ways to address this difficulty.
+constant index into an array variable imported from a DLL.  Any 
+multiword variable (arrays, structs, long long, etc) may trigger
+this error condition.  However, regardless of the exact data type
+of the offending exported variable, ld will always detect it, issue
+the warning, and exit.
+There are several ways to address this difficulty, regardless of the
+data type of the exported variable:
 One solution is to force one of the 'constants' to be a variable -- 
 that is, unknown and un-optimizable at compile time.  For arrays, 
 there are two possibilities: a) make the indexee (the array's address) 
@@ -1760,12 +1766,19 @@
    @{ volatile int t=1; extern_array[t] @}
 @end example
-For structs, the only option is to make the struct itself variable:
+For structs (and most other multiword data types) the only option 
+is to make the struct (or long long, or ...) itself variable:
 extern struct s extern_struct;
 extern_struct.field --> 
    @{ volatile struct s *t=&extern_struct; t->field @}
+@end example
+extern long long extern_ll;
+extern_ll -->
+  @{ volatile long long * local_ll=&extern_ll; *local_ll=... @}
 @end example
 A second method of dealing with this difficulty is to abandon


- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019