commit 32fb19371bc2901910de79444e87ee84779ce24c
author Russ Cox <rsc@golang.org> Tue Sep 30 12:43:49 2014 -0400
committer Russ Cox <rsc@golang.org> Tue Sep 30 12:43:49 2014 -0400
tree a7d5425c35a3509db15de9e40caff0a4e296b8c1
parent c09c8bb32595fc4b0bfcb1f6cedaf01040b05e1a

[release-branch.go1.3] cmd/5l, cmd/6l, cmd/8l: fix nacl binary corruption bug

««« CL 135050043 / 57dfd03985a9
cmd/5l, cmd/6l, cmd/8l: fix nacl binary corruption bug

NaCl requires the addition of a 32-byte "halt sled" at the end
of the text segment. This means that segtext.len is actually
32 bytes shorter than reality. The computation of the file offset
of the end of the data segment did not take this 32 bytes into
account, so if len and len+32 rounded up (by 64k) to different
values, the symbol table overwrote the last page of the data
segment.

The last page of the data segment is usually the C .string
symbols, which contain the strings used in error prints
by the runtime. So when this happens, your program
probably crashes, and then when it does, you get binary
garbage instead of all the usual prints.

The chance of hitting this with a randomly sized text segment
is 32 in 65536, or 1 in 2048.

If you add or remove ANY code while trying to debug this
problem, you're overwhelmingly likely to bump the text
segment one way or the other and make the bug disappear.

Correct all the computations to use segdata.fileoff+segdata.filelen
instead of trying to rederive segdata.fileoff.

This fixes the failure during the nacl/amd64p32 build.

TBR=iant
CC=golang-codereviews
https://golang.org/cl/135050043
»»»

LGTM=bradfitz
R=golang-codereviews
CC=adg, bradfitz, golang-codereviews, iant
https://golang.org/cl/151150044