code review 46780043: pkg/debug/elf: add C source for testdata binaries

debug/elf: add C source for testdata executables

This source file, when compiled with gcc 4.4.3 on Ubuntu lucid,
corresponds instruction for instruction to the binaries in the same
directory.

Shipping this source code file resolves http://bugs.debian.org/716853

[mstplbrg, 2013-12-31 17:03:34]

Hello golang-codereviews@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go

[iant, 2013-12-31 21:53:29]

CL description should start with "debug/elf"--omit "pkg/".

There are many other binaries in the test data, for example in
archive/tar/testdata.  And you haven't addressed the equally obvious issues in
debug/pe/testdata or debug/macho/testdata or debug/dwarf/testdata.

Adding unused source code files is meaningless.  It may possibly satisfy the
letter of the law but it certainly doesn't satisfy the spirit; there is in fact
no reasonable way to recreate these binaries.  I suggest we ask Debian whether
they would be satisfied if we added README files in the directories with binary
data explaining how the binaries were created.

[mstplbrg, 2013-12-31 21:57:49]

On 2013/12/31 21:53:29, iant wrote:
> CL description should start with "debug/elf"--omit "pkg/".
Done.

> There are many other binaries in the test data, for example in
> archive/tar/testdata.  And you haven't addressed the equally obvious issues in
> debug/pe/testdata or debug/macho/testdata or debug/dwarf/testdata.
Sorry, I should have said executables, not binaries.

debug/dwarf/testdata contains typedef.c
debug/macho/testdata contains hello.c
debug/pe/testdata contains hello.c

> Adding unused source code files is meaningless.  It may possibly satisfy the
> letter of the law but it certainly doesn't satisfy the spirit; there is in
fact
> no reasonable way to recreate these binaries.  I suggest we ask Debian whether
> they would be satisfied if we added README files in the directories with
binary
> data explaining how the binaries were created.
Well, having the source is a good-enough explanation of how the executables were
created, as per paultag@ (debian). I certainly won’t object to an additional
README :).

[mstplbrg, 2013-12-31 21:57:49]

On 2013/12/31 21:53:29, iant wrote:
> CL description should start with "debug/elf"--omit "pkg/".
Done.

> There are many other binaries in the test data, for example in
> archive/tar/testdata.  And you haven't addressed the equally obvious issues in
> debug/pe/testdata or debug/macho/testdata or debug/dwarf/testdata.
Sorry, I should have said executables, not binaries.

debug/dwarf/testdata contains typedef.c
debug/macho/testdata contains hello.c
debug/pe/testdata contains hello.c

> Adding unused source code files is meaningless.  It may possibly satisfy the
> letter of the law but it certainly doesn't satisfy the spirit; there is in
fact
> no reasonable way to recreate these binaries.  I suggest we ask Debian whether
> they would be satisfied if we added README files in the directories with
binary
> data explaining how the binaries were created.
Well, having the source is a good-enough explanation of how the executables were
created, as per paultag@ (debian). I certainly won’t object to an additional
README :).

[iant, 2013-12-31 22:33:11]

LGTM

OK, fair enough, I guess.

[iant, 2013-12-31 22:36:18]

*** Submitted as https://code.google.com/p/go/source/detail?r=8b8c7ba8d61c ***

debug/elf: add C source for testdata executables

This source file, when compiled with gcc 4.4.3 on Ubuntu lucid,
corresponds instruction for instruction to the binaries in the same
directory.

Shipping this source code file resolves http://bugs.debian.org/716853

R=golang-codereviews, iant
CC=golang-codereviews
https://codereview.appspot.com/46780043

Committer: Ian Lance Taylor <iant@golang.org>