[Bug ld/19803] gc-sections breaks PE DLL variable export

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19803

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #7 from Nick Clifton <nickc at redhat dot com> ---
(In reply to martin.koegler from comment #6)

Hi Martin,

> The last patch is incorrect. In my testcase, it still exports the removed 
> variable in the DLL export table:
> [Ordinal/Name Pointer] Table
>         [   0] testval
>
> So directly linking with the DLL produces a invalid binary.

Darn.  I was hoping changing the class to C_HIDDEN and the section to undefined
would be sufficient.

> May I ask, why you only adapt the implib generation? 

Because I am not a COFF/PE expert!  Nobody else seemed to want to work on this
problem, at there are several bug reports about it now, so I decided that I had
better have a go.  But as you can see, most of my patches have been based upon
guesswork.

> If you make sure, that the export table is correct [every exported symbol is
> not removed by gc-sections], shouldn't the export library generated from it
> be automatically correct too?

True - but it looks to me like the data structures for generating the export
table are set up far too early - ie before garbage collection - and the code in
the bfd library that performs the garbage collection has no knowledge of, or
access to, these data structures.

> In my option, your first patch didn't break gc-sections. The windows default
> is to export all (global?) symbols from a DLL, if no specific export list is
> provided via a DEF file.

Ah - OK, in which case most of the first patch is probably not needed.  Only
the change to process_def_file_and_drective() should be necessary.

But - if all global symbols are going to be exported, doesn't that mean that
garbage collection is going to be effectively useless.  (For a DLL anyway). 
How many sections are there that contain data/code and which do not have at
least one global symbol associated with them ?

Hmm, maybe garbage collection would be worthwhile if a DEF file is used.  Could
you test to see if, with patch 1 applied, and a DEF file is used to only export
some of the symbols, that garbage collection does indeed throw away unused data
and code in a DLL ?

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.