Re: globals in (out of) crt0

[David Laight <david%l8s.co.uk@localhost>]

On Sun, Nov 27, 2016 at 03:20:26AM +0000, David Holland wrote:
> While discussing the Emacs problems with Joerg (see PR 51654 for the
> gory details)

presumably copied from sendmail - which used to write
[end, break()) to file to speed startup.

> the conclusion we came to is that the best real fix (as
> opposed to the workaround of disabling ASLR) is to shift the
> __ps_strings global from crt0 to libc; then it won't be referenced
> directly by programs, won't be in the linked program's BSS, and won't
> be accidentally saved when Emacs dumps. Instead, libc will provide a
> private entry point to assign the value of __ps_strings. (This also
> turns out to simplify the piece of libc initialization that is
> crashing Emacs.)
> 
> In the name of tidiness one can also move the __progname and environ
> globals. It is my belief that this will not break compat, because
> these symbols always needed to be exported from the executable so libc
> could manipulate them. The patch does cause __progname to shift from
> libc .bss to .data so it's initialized to ""; the copy relocation to
> provide the initialization won't be in old executables, but old
> executables have an already-initialized copy, so this shouldn't cause
> compat problems either.
> 
> (If I'm missing something in this analysis, please speak up.)

Possibly ...

But maybe only for programs that dlopen() libc (so it's symbols
are in a different namespace).
Anything that did that might end up with different libraries
referencing different memory when looking for the same data.
The 'relocation' done for elf .so data is such a cludge it
ought to have been stillborn :-)


	David

-- 
David Laight: david%l8s.co.uk@localhost