https://sourceware.org/bugzilla/show_bug.cgi?id=19803
--- Comment #10 from martin.koegler at chello dot at ---
(In reply to Nick Clifton from comment #7)
> 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 ?
We can justify the current behaviour, that gc-sections should shrink the build
as far as possible, but must not change the interface (=exported symbols).
On Linux:
$ cat t1.c
void add()
{}
$ cat t2.c
void sub()
{}
$ gcc -shared -o t.so t1.c t2.c -Wl,--print-gc-sections -Wl,--gc-sections
$ nm t.so
00000000000006e5 T add
0000000000201030 B __bss_start
0000000000201030 b completed.6337
w __cxa_finalize@@GLIBC_2.2.5
0000000000000600 t deregister_tm_clones
0000000000000670 t __do_global_dtors_aux
0000000000200df8 t __do_global_dtors_aux_fini_array_entry
0000000000201028 d __dso_handle
0000000000200e08 d _DYNAMIC
0000000000201030 D _edata
0000000000201038 B _end
00000000000006f4 T _fini
00000000000006b0 t frame_dummy
0000000000200df0 t __frame_dummy_init_array_entry
00000000000007a8 r __FRAME_END__
0000000000201000 d _GLOBAL_OFFSET_TABLE_
w __gmon_start__
00000000000005a8 T _init
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
0000000000200e00 d __JCR_END__
0000000000200e00 d __JCR_LIST__
w _Jv_RegisterClasses
0000000000000630 t register_tm_clones
00000000000006eb T sub
0000000000201030 d __TMC_END__
So gc-section on Linux (openSuSE 42.1) does not affect the auto-exported
symbols.
--
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
