cmd/link: reserve space for dynamic section for GOOS=nacl

[4ad]

The Native Client sandbox has support for dynamic code generation and patching at runtime. This is done safely using the regular NaCl checks so it preserves the sandbox properties.

Address space for dynamic code is reserved with the NaCl dyncode_create system call. Go currently has access to this system call. The actual address space comes from a dynamic section created at load time by NaCl. This section is placed between the .text and .rodata sections.

Currently the Go linker places the .rodata section right next to the .text section, so the NaCl dynamic loader doesn't have any space to create the dynamic text section. I propose for GOOS=nacl we leave a sizeable gap between .text and .rodata so that the NaCl dynamic loader has enough space to create the dynamic text section. This is trivial to accomplish, it's a one line-patch to go/src/cmd/link/internal/ld/data.go:/address/, I tested it and it works.

One reason to enable this functionality would be to allow creating performant interpreters that use JIT technology.

Another reason would be the fact that NaCl might stop supporting non-dynamic-text-enabled executables in the future. The file native_client/src/trusted/service_runtime/sel_ldr.h has the following comment in it:

  /*
   * may reject nexes that are incompatible w/ dynamic-text in the near future
   */

For people who do not wish to have access to dynamic code generation NaCl provides the NACL_DISABLE_DYNAMIC_LOADING environment variable, which turns off dynamic text section generation.

[mdempsky]

Are there any downsides to doing this? I'm guessing it just bloats the executable a little bit because of internal padding?

If that's the only issue, this seems fine to me.

[4ad]

It doesn't bloat the executable because this just sets a different virtual load address for the .rodata segment. There is no actual space wasted in the executable.

A downside would be that in the current NaCl implementation a process can't use that memory for anything else, and a process has only 32 (31?) bits of address space. We would probably need to size this gap to be the same as the one set by the C toolchain instead of making it too big.

[mdempsky]

I see. Matching the NaCl C toolchain sounds reasonable to me.

[rsc]

Yes, go ahead, please do what the C toolchain does. If this causes problems for any of our uses we can back it out, although I doubt we'll need to. Thanks.