Re: Initialized variables in .bss

[Florian Weimer <fweimer at redhat dot com>]

On 11/24/2015 10:14 PM, Segher Boessenkool wrote:

>> However, there is still a subtle difference for non-static objects.
>> Adding the initializer turns a tentative definition into a definite one,
>> and it seems that this can't go into .bss.
> 
> extern int a;
> int a = 0;
> 
> and
> 
> int b;
> int b = 0;
> 
> go to .bss just fine.  Did you mean something different?

This is what I meant.  I still see a subtle difference in the generated
executable, but it is not what I thought.  One should be using proper
tools.  This is the diff after adding a couple of zero initializers:

@@ -810,7 +810,7 @@
 00000000003958f8 d
__elf_set___libc_thread_subfreeres_element___rpc_thread_destroy__
 00000000003958e8 d
__elf_set___libc_thread_subfreeres_element_strerror_thread_freeres__
 00000000001699a0 r empty_path_elem
-000000000039ea00 b _end
+000000000039e9f8 b _end
 00000000000fd6a0 T endaliasent
 00000000000dfaa0 T endfsent
 00000000000b3690 T endgrent
@@ -1287,14 +1287,14 @@
 00000000000216c0 T __gconv_get_modules_db
 0000000000022d10 t __gconv_get_path
 0000000000028c00 t __gconv_load_cache
-000000000039e378 b __gconv_lock
+000000000039a8e8 b __gconv_lock
 0000000000028eb0 t __gconv_lookup_cache
-000000000039e388 b __gconv_max_path_elem_len
+000000000039e380 b __gconv_max_path_elem_len
 00000000001620a9 r gconv_module_ext
-000000000039e380 b __gconv_modules_db
+000000000039e378 b __gconv_modules_db
 0000000000020f20 t __gconv_open
-000000000039e398 b __gconv_path_elem
-000000000039e390 b __gconv_path_envvar
+000000000039e390 b __gconv_path_elem
+000000000039e388 b __gconv_path_envvar
 00000000000230f0 t __gconv_read_conf
 0000000000029310 t __gconv_release_cache
 00000000000293c0 t __gconv_release_shlib
@@ -3412,7 +3412,7 @@
 0000000000397920 d __libc_utmp_file_functions
 000000000039a438 d __libc_utmp_file_name
 000000000039a430 d __libc_utmp_jump_table
-000000000039e9f8 b __libc_utmp_lock
+000000000039e164 b __libc_utmp_lock
 00000000003978e0 d __libc_utmp_unknown_functions
 000000000007a350 T __libc_valloc
 00000000001656d0 r __libc_version
@@ -4155,7 +4155,7 @@
 000000000039b880 b old_realloc_hook
 000000000011b980 t __old_realpath
 000000000039bad0 b old_tz
-000000000039a8e8 b once
+000000000039a8ec b once
 000000000039d77c b once.11214
 000000000039dae4 b once.13803
 000000000039bf64 b once.14680

So __gconv_lock moves towards the end, somehow improving the overall
shared object size:

1659534   20312   17192 1697038  19e50e build-pristine/libc.so.6
1659534   20312   17184 1697030  19e506 build/libc.so.6

(In the diff above, - is the pristine variant (without initializer) and
+ has the initializer.)

Anyway, it means I can submit my patch because the GCC optimization does
what we need.

Thanks,
Florian