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: List-Archive: List-Post: List-Help: , 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 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 CC: cygwin-apps AT cygwin DOT com Subject: Re: binutils patch [Was: Re: ncurses announcement - trial run] References: <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> Content-Type: multipart/mixed; boundary="------------040502040804000603070600" This is a multi-part message in MIME format. --------------040502040804000603070600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Here are the other two patches, recently submitted to binutils@. --Chuck --------------040502040804000603070600 Content-Type: text/plain; name="ld_auto_import.changelog" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ld_auto_import.changelog" 2001-09-21 Charles Wilson * 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. --------------040502040804000603070600 Content-Type: text/plain; name="ld_texinfo.changelog" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ld_texinfo.changelog" 2001-09-21 Charles Wilson * ld.texinfo(enable-auto-import): clarify the explanation. --------------040502040804000603070600 Content-Type: text/plain; name="ld_auto_import.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ld_auto_import.patch" 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; #endif 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 () +{ +#ifdef DLL_SUPPORT + return pe_data_import_dll; +#else + return "unknown"; +#endif +} static void pe_find_data_imports () --------------040502040804000603070600 Content-Type: text/plain; name="ld_texinfo.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ld_texinfo.patch" 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: @example extern struct s extern_struct; extern_struct.field --> @{ volatile struct s *t=&extern_struct; t->field @} +@end example + +@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 --------------040502040804000603070600--