gccgo testcase: binary testdata for libgo/go/debug/elf/file_test.go

gccgo testcase: binary testdata for libgo/go/debug/elf/file_test.go

[Lynn A. Boger]

Hi,

I'm working on a patch submission for gccgo to add the R_PPC64 
relocation definitions to libgo/go/debug/elf/elf.go.  Along with this 
submission I was going to update the testcase file_test.go from the same 
directory so it would test the new defines for ppc64 relocation.  This 
test currently reads files from libgo/go/debug/elf/testdata which exist 
in svn as executable and relocatable files that were compiled from 
various gcc versions and on various platforms.

How should I submit these testdata files, since they are binary files 
and not patch files?

- Lynn

Re: gccgo testcase: binary testdata for libgo/go/debug/elf/file_test.go

[Ian Lance Taylor]

On Wed, Oct 15, 2014 at 1:41 PM, Lynn A. Boger
<laboger@linux.vnet.ibm.com> wrote:
>
> I'm working on a patch submission for gccgo to add the R_PPC64 relocation
> definitions to libgo/go/debug/elf/elf.go.  Along with this submission I was
> going to update the testcase file_test.go from the same directory so it
> would test the new defines for ppc64 relocation.  This test currently reads
> files from libgo/go/debug/elf/testdata which exist in svn as executable and
> relocatable files that were compiled from various gcc versions and on
> various platforms.
>
> How should I submit these testdata files, since they are binary files and
> not patch files?

Ideally all submissions to gccgo should follow the process described
at http://golang.org/doc/gccgo_contribute.html .  This is not strictly
required in that I will take care of it for you, but it makes life a
lot easier for me if you do it that way.  And as a bonus it handles
binary files just fine.

If that's not going to work just send the binary files to gcc-patches
as an attachment.  Put the patch itself in one attachment, or inline
in the e-mail message, and put the binary files in another.  Please
make sure that all the binaries are compiled from the hello.c file in
that directory; if that is not possible, you will need to provide the
sources that you are compiling, to satisfy Debian's requirements on
binaries in test data.  (And at that point we'll probably have to
start thinking about a README to explain where the files come from.)

Thanks!

Ian

Re: gccgo testcase: binary testdata for libgo/go/debug/elf/file_test.go

[Lynn A. Boger]

I will start with the gccgo contribution process from golang.

Thanks!

Lynn

On 10/15/2014 08:26 PM, Ian Lance Taylor wrote:
> On Wed, Oct 15, 2014 at 1:41 PM, Lynn A. Boger
> <laboger@linux.vnet.ibm.com> wrote:
>> I'm working on a patch submission for gccgo to add the R_PPC64 relocation
>> definitions to libgo/go/debug/elf/elf.go.  Along with this submission I was
>> going to update the testcase file_test.go from the same directory so it
>> would test the new defines for ppc64 relocation.  This test currently reads
>> files from libgo/go/debug/elf/testdata which exist in svn as executable and
>> relocatable files that were compiled from various gcc versions and on
>> various platforms.
>>
>> How should I submit these testdata files, since they are binary files and
>> not patch files?
> Ideally all submissions to gccgo should follow the process described
> at http://golang.org/doc/gccgo_contribute.html .  This is not strictly
> required in that I will take care of it for you, but it makes life a
> lot easier for me if you do it that way.  And as a bonus it handles
> binary files just fine.
>
> If that's not going to work just send the binary files to gcc-patches
> as an attachment.  Put the patch itself in one attachment, or inline
> in the e-mail message, and put the binary files in another.  Please
> make sure that all the binaries are compiled from the hello.c file in
> that directory; if that is not possible, you will need to provide the
> sources that you are compiling, to satisfy Debian's requirements on
> binaries in test data.  (And at that point we'll probably have to
> start thinking about a README to explain where the files come from.)
>
> Thanks!
>
> Ian
>