Re: [PATCH RFC] fork: reduce chances for "address space is already occupied" errors

[Michael Haubenwallner <michael dot haubenwallner at ssi-schaefer dot com>]

On 4/12/19 7:40 PM, Corinna Vinschen wrote:
> Hi Michael,

> Nick Clifton, one of the binutils maintainers, made the following
> suggestion in PM:
> 
> Allow the ld flag --enable-auto-image-base to take a filename as
> argument.> 
> The idea: The file is used by ld to generate the start address
> for the next built DLL.  Mechanism:
> 
> 1.1. If ld links a DLL and if the file given to --enable-auto-image-base
>      doesn't exist, ld will give the DLL the start address of the
>      auto image base range.
> 
> 1.2: Next time, if ld links a DLL and if the file given to
>      --enable-auto-image-base exists, it will use the address in that
>      file as the start address for th just built DLL.
> 
> 2. It will store that address, plus the size of the DLL, rounded up to
>    64K, in that file.

The rounding up is fine to get some alignment for the base address itself,
but it feels irrelevant if it was for "finding the next base" only.

> 3. If the auto image base range is at an end, ld will wrap back to
>    the start address of the auto image base range.> 
> TBD: A way to enable this feature without having to change all
>      packages' build systems.

As the --enable-auto-image-base flag does not name any method for finding
the image base beyond "automatic", IMHO using some predefined control file
under the hoods should be fine.

Beyond holding the last image base and the range, such an auto image base
control file could control the actual behaviour as well, as in either
"use the -o argument" or "use next base within range".

Hence some versioning of that file's content might be resonable.  And
for parallel builds, "finding the next base" needs some synchronization.

What about hardcoding (the default of) such a filename into ld itself?  E.g.
"./configure --with-auto-image-base-control-file=/var/lib/ld/auto-image-base"

Also, I could think of binutils' configure options like this instead:
 --with-auto-image-base=control-file=/path/to/file
 --with-auto-image-base=dash-o-argument # current behaviour, no control file support

And to set the defaults of that control file:
 --with-auto-image-base-control-file-default-mode=[dash-o-argument|control-file]
 --with-auto-image-base-control-file-default-range=0x123456789abcdef:0xfedcba9876543210

> That way you could build hundreds of DLLs in a project and use them
> immediately without having to rebase.
> 
> This is just in a discussion state, nothing has happend yet, but
> what do you think in general?

This does make a lot of sense to me in general, although package managers
still need to use the Cygwin rebase database, as in the long run that range
will exceed.  But for Gentoo Prefix in particular, this would help during
bootstrap, before the Cygwin rebase database is set up inside the Prefix.

Thanks!
/haubi/