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.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
