Re: [patch] fix uninitialized variable in dynamic linker

[Roland McGrath <roland at hack dot frob dot com>]

If it is indeed right to zero the entire structure, then the cleanest way
to do that is just to change:

  struct dl_start_final_info info;

to:

  struct dl_start_final_info info = {};

Then the compiler is responsible for figuring out the memset equivalent.

Heretofore it never seemed necessary, suggesting that l_info was the only
part of struct link_map that is not explicitly initialized and that is
actually consulted during bootstrap relocation.  If that was indeed true
before, and recent MIPS additions to its l_mach (struct link_map_machine)
were the only thing that caused any other part of bootstrap_map to need
initialization, then there is a case to be made for initializing only those
recently-added fields.  The general logic trading off blind zeroing as
"future-proofing" vs the performance cost has a different calculus here
(and often in libc in general), because we are talking about adding some
static cost to every program's startup across the entire system.

Since most machines define PI_STATIC_AND_HIDDEN and so do not use this code
path (bootstrap_map on the stack), I think we are less concerned than we
otherwise would be about the blind zeroing doing excess dead stores.
AFAICT the machines that fail to define PI_STATIC_AND_HIDDEN are aarch64,
arm, hppa, m68k, mips*, powerpc*, tile*.  For aarch64 I suspect it is just
an oversight.  For arm I suspect it could be enabled unconditionally now
that we require more recent compilers; certainly it could be enabled by a
configure test, though I don't know how to write one (since I don't know
the circumstances in which it might not work).  For the others I don't
personally care about regressions in microoptimization.


Thanks,
Roland