This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH] pei386, ld auto-import


Nick Clifton wrote:

 
> As you have probably guessed this version of the patch is unsuitable
> too.  There are two problems:
> 
>   1. The new function pe_get_data_import_dll_name() is defined inside
>      #ifdef DLL_SUPPORT code, and so is not present for targets like
>      arm-epoc-pe.  (This of course is easily fixed).


Oops.  I intended for it to be outside of DLL_SUPPORT.  However, that's 
a moot point, given:


> 
>   2. The new function pe_get_data_import_dll_name() is a global
>      function and will be multiply defined if ld is configured for
>      more than one PE target.  eg when building ld with
>      --enable-targets=all specified.  This is much harder to fix.


Ah. So having an unitialized variable for non-DLL_SUPPORT targets is 
good; within the DLL_SUPPORT code path it becomes initialized.  Then in 
pe-dll.c, test for initialization.  Something you can do with vars that 
you can't easily do with functions.


> I have applied a workaround instead - of moving the definition of the
> pe_data_import_dll variable outside of the #ifdef DLL_SUPPORT
> controlled code - however if you feel that this is unsuitable then
> please feel free to submit a different solution.


No, your version seems fine to me.  As long as there is a *reason* to 
share a variable between two files, and that variable is defined for all 
environments (e.g. no build breakages) then I'm happy.  Here, using a 
variable allows you to do things that aren't easily possible with 
"accessor" functions, like my patch tried to do.

Discussion continued on other thread.

--Chuck



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]