Illegal instruction when running go binaries in qemux86

Illegal instruction when running go binaries in qemux86

[Paul Barker]

So, after fixing all my build issues I now have runtime issues :(

Software written in go fails on qemux86 with illegal instruction traps:

    root@qemux86:~# netns ls
    [   18.984298] traps: netns[491] trap invalid opcode ip:807b541
sp:bf9694bc error:0[   18.985354]  in netns[8048000+1c3000]
    Illegal instruction
    root@qemux86:~# runc
    traps: runc[492] trap invalid opcode ip:807b561 sp:bff6ec1c
error:0[   21.604966]  in runc[8048000+457000]
    Illegal instruction

I've done a git bisect and tracked this down to commit 20b35747
"qemuboot.conf: make cpus match built artifacts" on master. This has
been backported to pyro as commit d9456782 and I've confirmed that I
have the same issue on pyro. On pyro in particular this is a
regression as the patch was backported after pyro was released.

The important change is:

    -QB_CPU_x86 = "-cpu qemu32"
    +QB_CPU_x86 = "-cpu pentium2"

So my guess was that the go toolchain isn't limiting itself to the
instructions supported by pentium2.

To fix things I've added the following line to meta/classes/go.bbclass
and meta/recipes-devtools/go/go-common.inc:

    export GO386 = "387"

As documented in https://golang.org/doc/install/source, this ensures
that sse2 instructions aren't used. This fixes the issue and I now
have working go binaries on qemux86 :)

So my question is: should we just set GO386 = "387" so that it applies
to all go binaries and accept the slight loss of performance on x86
systems that do support sse2 instructions? Or should we make this
MACHINE specific so that sse2 instructions can be used where
supported?

Whatever we do will need backporting to pyro as well.

Cheers,

-- 
Paul Barker
Togán Labs Ltd

Re: Illegal instruction when running go binaries in qemux86

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

On 5 October 2017 at 15:23, Paul Barker <pbarker@toganlabs.com> wrote:

> So my question is: should we just set GO386 = "387" so that it applies
> to all go binaries and accept the slight loss of performance on x86
> systems that do support sse2 instructions? Or should we make this
> MACHINE specific so that sse2 instructions can be used where
> supported?
>

Definitely machine-specific.  Need a way of mapping from OE tunes to Go
options that control the instructions used.

Ross

[-- Attachment #2: Type: text/html, Size: 846 bytes --]

Re: Illegal instruction when running go binaries in qemux86

[Paul Barker]

On Thu, Oct 5, 2017 at 3:31 PM, Burton, Ross <ross.burton@intel.com> wrote:
> On 5 October 2017 at 15:23, Paul Barker <pbarker@toganlabs.com> wrote:
>>
>> So my question is: should we just set GO386 = "387" so that it applies
>> to all go binaries and accept the slight loss of performance on x86
>> systems that do support sse2 instructions? Or should we make this
>> MACHINE specific so that sse2 instructions can be used where
>> supported?
>
>
> Definitely machine-specific.  Need a way of mapping from OE tunes to Go
> options that control the instructions used.
>
> Ross

Looking again, we already have go_map_arm() in goarch.bbclass to set
HOST_GOARM and TARGET_GOARM. We probably need to do the same for the
GO386 variable.

Cheers,

-- 
Paul Barker
Togán Labs Ltd

Re: Illegal instruction when running go binaries in qemux86

[Khem Raj]

On Thu, Oct 5, 2017 at 7:23 AM, Paul Barker <pbarker@toganlabs.com> wrote:
> So, after fixing all my build issues I now have runtime issues :(
>
> Software written in go fails on qemux86 with illegal instruction traps:
>
>     root@qemux86:~# netns ls
>     [   18.984298] traps: netns[491] trap invalid opcode ip:807b541
> sp:bf9694bc error:0[   18.985354]  in netns[8048000+1c3000]
>     Illegal instruction
>     root@qemux86:~# runc
>     traps: runc[492] trap invalid opcode ip:807b561 sp:bff6ec1c
> error:0[   21.604966]  in runc[8048000+457000]
>     Illegal instruction
>
> I've done a git bisect and tracked this down to commit 20b35747
> "qemuboot.conf: make cpus match built artifacts" on master. This has
> been backported to pyro as commit d9456782 and I've confirmed that I
> have the same issue on pyro. On pyro in particular this is a
> regression as the patch was backported after pyro was released.
>
> The important change is:
>
>     -QB_CPU_x86 = "-cpu qemu32"
>     +QB_CPU_x86 = "-cpu pentium2"
>

We use -march=i586 for qemux86 which actually maps to pentium not
pentium2 which is i686 I think, this should be corrected to be with the
spirit of the patch. From gcc speak i586 means Intel Pentium CPU with
no MMX support.
and pentium2 means Intel Pentium II CPU, based on Pentium Pro core
with MMX instruction set support, I am assuming qemu means same.

> So my guess was that the go toolchain isn't limiting itself to the
> instructions supported by pentium2.
>
> To fix things I've added the following line to meta/classes/go.bbclass
> and meta/recipes-devtools/go/go-common.inc:
>
>     export GO386 = "387"
>
> As documented in https://golang.org/doc/install/source, this ensures
> that sse2 instructions aren't used. This fixes the issue and I now
> have working go binaries on qemux86 :)
>
> So my question is: should we just set GO386 = "387" so that it applies
> to all go binaries and accept the slight loss of performance on x86
> systems that do support sse2 instructions? Or should we make this
> MACHINE specific so that sse2 instructions can be used where
> supported?
>

We should have goarch set correctly, since i586 really did not have
sse2, we need this mapping based on -march added in go recipes
much like arm

> Whatever we do will need backporting to pyro as well.
>
> Cheers,
>
> --
> Paul Barker
> Togán Labs Ltd
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: Illegal instruction when running go binaries in qemux86

[Paul Barker]

On Thu, Oct 5, 2017 at 3:35 PM, Paul Barker <pbarker@toganlabs.com> wrote:
> On Thu, Oct 5, 2017 at 3:31 PM, Burton, Ross <ross.burton@intel.com> wrote:
>> On 5 October 2017 at 15:23, Paul Barker <pbarker@toganlabs.com> wrote:
>>>
>>> So my question is: should we just set GO386 = "387" so that it applies
>>> to all go binaries and accept the slight loss of performance on x86
>>> systems that do support sse2 instructions? Or should we make this
>>> MACHINE specific so that sse2 instructions can be used where
>>> supported?
>>
>>
>> Definitely machine-specific.  Need a way of mapping from OE tunes to Go
>> options that control the instructions used.
>>
>> Ross
>
> Looking again, we already have go_map_arm() in goarch.bbclass to set
> HOST_GOARM and TARGET_GOARM. We probably need to do the same for the
> GO386 variable.
>

I'm looking at what I can use to determine if sse2 is supported for a
given machine/tune.

In TUNE_FEATURES I could check for "core2" or "corei7" based on what's
in oe-core, but not sure this will cover tunings which might be
defined in other layers.

Alternatively I could check TUNE_CCARGS for "-msse2" or later but that
feels dirty.

Any suggestions on this?

-- 
Paul Barker
Togán Labs Ltd

Re: Illegal instruction when running go binaries in qemux86

[Khem Raj]

On Mon, Oct 9, 2017 at 6:15 AM, Paul Barker <pbarker@toganlabs.com> wrote:
> On Thu, Oct 5, 2017 at 3:35 PM, Paul Barker <pbarker@toganlabs.com> wrote:
>> On Thu, Oct 5, 2017 at 3:31 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>> On 5 October 2017 at 15:23, Paul Barker <pbarker@toganlabs.com> wrote:
>>>>
>>>> So my question is: should we just set GO386 = "387" so that it applies
>>>> to all go binaries and accept the slight loss of performance on x86
>>>> systems that do support sse2 instructions? Or should we make this
>>>> MACHINE specific so that sse2 instructions can be used where
>>>> supported?
>>>
>>>
>>> Definitely machine-specific.  Need a way of mapping from OE tunes to Go
>>> options that control the instructions used.
>>>
>>> Ross
>>
>> Looking again, we already have go_map_arm() in goarch.bbclass to set
>> HOST_GOARM and TARGET_GOARM. We probably need to do the same for the
>> GO386 variable.
>>
>
> I'm looking at what I can use to determine if sse2 is supported for a
> given machine/tune.
>
> In TUNE_FEATURES I could check for "core2" or "corei7" based on what's
> in oe-core, but not sure this will cover tunings which might be
> defined in other layers.
>
> Alternatively I could check TUNE_CCARGS for "-msse2" or later but that
> feels dirty.
>
> Any suggestions on this?
>

For cross compile there is no easy way, I would think using a map is
probably the
best thing we can do,

Re: Illegal instruction when running go binaries in qemux86

[Paul Barker]

On Mon, Oct 9, 2017 at 5:04 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Mon, Oct 9, 2017 at 6:15 AM, Paul Barker <pbarker@toganlabs.com> wrote:
>> On Thu, Oct 5, 2017 at 3:35 PM, Paul Barker <pbarker@toganlabs.com> wrote:
>>> On Thu, Oct 5, 2017 at 3:31 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>>> On 5 October 2017 at 15:23, Paul Barker <pbarker@toganlabs.com> wrote:
>>>>>
>>>>> So my question is: should we just set GO386 = "387" so that it applies
>>>>> to all go binaries and accept the slight loss of performance on x86
>>>>> systems that do support sse2 instructions? Or should we make this
>>>>> MACHINE specific so that sse2 instructions can be used where
>>>>> supported?
>>>>
>>>>
>>>> Definitely machine-specific.  Need a way of mapping from OE tunes to Go
>>>> options that control the instructions used.
>>>>
>>>> Ross
>>>
>>> Looking again, we already have go_map_arm() in goarch.bbclass to set
>>> HOST_GOARM and TARGET_GOARM. We probably need to do the same for the
>>> GO386 variable.
>>>
>>
>> I'm looking at what I can use to determine if sse2 is supported for a
>> given machine/tune.
>>
>> In TUNE_FEATURES I could check for "core2" or "corei7" based on what's
>> in oe-core, but not sure this will cover tunings which might be
>> defined in other layers.
>>
>> Alternatively I could check TUNE_CCARGS for "-msse2" or later but that
>> feels dirty.
>>
>> Any suggestions on this?
>>
>
> For cross compile there is no easy way, I would think using a map is
> probably the
> best thing we can do,

This is my intention, just trying to work out what I can map from.
What I'm currently thinking is, in rough pseudocode:

go_map_386():
    if "core2" or "corei7" in TUNE_FEATURES:
        return "sse2"
    else:
        return "387"

Then set TARGET_GO386 and HOST_GO386 appropriately. This can then
determine the final "export GO386 = ...." depending on if we're
building for host or target. Much the same way GOARM is currently
handled.

Cheers,

-- 
Paul Barker
Togán Labs Ltd

Re: Illegal instruction when running go binaries in qemux86

[Khem Raj]

On Mon, Oct 9, 2017 at 9:16 AM, Paul Barker <pbarker@toganlabs.com> wrote:
> On Mon, Oct 9, 2017 at 5:04 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Mon, Oct 9, 2017 at 6:15 AM, Paul Barker <pbarker@toganlabs.com> wrote:
>>> On Thu, Oct 5, 2017 at 3:35 PM, Paul Barker <pbarker@toganlabs.com> wrote:
>>>> On Thu, Oct 5, 2017 at 3:31 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>>>> On 5 October 2017 at 15:23, Paul Barker <pbarker@toganlabs.com> wrote:
>>>>>>
>>>>>> So my question is: should we just set GO386 = "387" so that it applies
>>>>>> to all go binaries and accept the slight loss of performance on x86
>>>>>> systems that do support sse2 instructions? Or should we make this
>>>>>> MACHINE specific so that sse2 instructions can be used where
>>>>>> supported?
>>>>>
>>>>>
>>>>> Definitely machine-specific.  Need a way of mapping from OE tunes to Go
>>>>> options that control the instructions used.
>>>>>
>>>>> Ross
>>>>
>>>> Looking again, we already have go_map_arm() in goarch.bbclass to set
>>>> HOST_GOARM and TARGET_GOARM. We probably need to do the same for the
>>>> GO386 variable.
>>>>
>>>
>>> I'm looking at what I can use to determine if sse2 is supported for a
>>> given machine/tune.
>>>
>>> In TUNE_FEATURES I could check for "core2" or "corei7" based on what's
>>> in oe-core, but not sure this will cover tunings which might be
>>> defined in other layers.
>>>
>>> Alternatively I could check TUNE_CCARGS for "-msse2" or later but that
>>> feels dirty.
>>>
>>> Any suggestions on this?
>>>
>>
>> For cross compile there is no easy way, I would think using a map is
>> probably the
>> best thing we can do,
>
> This is my intention, just trying to work out what I can map from.
> What I'm currently thinking is, in rough pseudocode:
>
> go_map_386():
>     if "core2" or "corei7" in TUNE_FEATURES:
>         return "sse2"
>     else:
>         return "387"
>

Perhaps inverse is easier, meaning, set 387 for i586, i486 and i386
and leave the
defaults as it is for other variants

> Then set TARGET_GO386 and HOST_GO386 appropriately. This can then
> determine the final "export GO386 = ...." depending on if we're
> building for host or target. Much the same way GOARM is currently
> handled.
>
> Cheers,
>
> --
> Paul Barker
> Togán Labs Ltd

Re: Illegal instruction when running go binaries in qemux86

[Paul Barker]

On Mon, Oct 9, 2017 at 5:49 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Mon, Oct 9, 2017 at 9:16 AM, Paul Barker <pbarker@toganlabs.com> wrote:
>> On Mon, Oct 9, 2017 at 5:04 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Mon, Oct 9, 2017 at 6:15 AM, Paul Barker <pbarker@toganlabs.com> wrote:
>>>>
>>>> I'm looking at what I can use to determine if sse2 is supported for a
>>>> given machine/tune.
>>>>
>>>> In TUNE_FEATURES I could check for "core2" or "corei7" based on what's
>>>> in oe-core, but not sure this will cover tunings which might be
>>>> defined in other layers.
>>>>
>>>> Alternatively I could check TUNE_CCARGS for "-msse2" or later but that
>>>> feels dirty.
>>>>
>>>> Any suggestions on this?
>>>>
>>>
>>> For cross compile there is no easy way, I would think using a map is
>>> probably the
>>> best thing we can do,
>>
>> This is my intention, just trying to work out what I can map from.
>> What I'm currently thinking is, in rough pseudocode:
>>
>> go_map_386():
>>     if "core2" or "corei7" in TUNE_FEATURES:
>>         return "sse2"
>>     else:
>>         return "387"
>>
>
> Perhaps inverse is easier, meaning, set 387 for i586, i486 and i386
> and leave the
> defaults as it is for other variants
>

Sadly that won't cover it. We'd also need to cover Pentium variants
pre-Pentium4 and early AMD variants. It's SSE2 which is needed not the
original SSE instructions.

Do the names in TUNE_FEATURES match those in
https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/x86-Options.html#x86-Options?
If so I might be able to build a rough map from that documentation.

Cheers,

-- 
Paul Barker
Togán Labs Ltd

Re: Illegal instruction when running go binaries in qemux86

[Andre McCurdy]

On Mon, Oct 9, 2017 at 10:01 AM, Paul Barker <pbarker@toganlabs.com> wrote:
> On Mon, Oct 9, 2017 at 5:49 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Mon, Oct 9, 2017 at 9:16 AM, Paul Barker <pbarker@toganlabs.com> wrote:
>>> On Mon, Oct 9, 2017 at 5:04 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>> On Mon, Oct 9, 2017 at 6:15 AM, Paul Barker <pbarker@toganlabs.com> wrote:
>>>>>
>>>>> I'm looking at what I can use to determine if sse2 is supported for a
>>>>> given machine/tune.
>>>>>
>>>>> In TUNE_FEATURES I could check for "core2" or "corei7" based on what's
>>>>> in oe-core, but not sure this will cover tunings which might be
>>>>> defined in other layers.
>>>>>
>>>>> Alternatively I could check TUNE_CCARGS for "-msse2" or later but that
>>>>> feels dirty.
>>>>>
>>>>> Any suggestions on this?
>>>>>
>>
>> Perhaps inverse is easier, meaning, set 387 for i586, i486 and i386
>> and leave the
>> defaults as it is for other variants
>
> Sadly that won't cover it. We'd also need to cover Pentium variants
> pre-Pentium4 and early AMD variants. It's SSE2 which is needed not the
> original SSE instructions.
>

Does testing X86ARCH32 work?

Re: Illegal instruction when running go binaries in qemux86

[Mark Hatle]

On 10/9/17 12:11 PM, Andre McCurdy wrote:
> On Mon, Oct 9, 2017 at 10:01 AM, Paul Barker <pbarker@toganlabs.com> wrote:
>> On Mon, Oct 9, 2017 at 5:49 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Mon, Oct 9, 2017 at 9:16 AM, Paul Barker <pbarker@toganlabs.com> wrote:
>>>> On Mon, Oct 9, 2017 at 5:04 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>> On Mon, Oct 9, 2017 at 6:15 AM, Paul Barker <pbarker@toganlabs.com> wrote:
>>>>>>
>>>>>> I'm looking at what I can use to determine if sse2 is supported for a
>>>>>> given machine/tune.
>>>>>>
>>>>>> In TUNE_FEATURES I could check for "core2" or "corei7" based on what's
>>>>>> in oe-core, but not sure this will cover tunings which might be
>>>>>> defined in other layers.
>>>>>>
>>>>>> Alternatively I could check TUNE_CCARGS for "-msse2" or later but that
>>>>>> feels dirty.
>>>>>>
>>>>>> Any suggestions on this?
>>>>>>
>>>
>>> Perhaps inverse is easier, meaning, set 387 for i586, i486 and i386
>>> and leave the
>>> defaults as it is for other variants
>>
>> Sadly that won't cover it. We'd also need to cover Pentium variants
>> pre-Pentium4 and early AMD variants. It's SSE2 which is needed not the
>> original SSE instructions.
>>

This is why 'TUNE_FEATURES' was introduced.  If SSE2 (or something else) is need
for proper configuration, then we should add a specific tune_feature and update
the corresponding tunes.

--Mark

> Does testing X86ARCH32 work?
> 

Re: Illegal instruction when running go binaries in qemux86

[Paul Barker]

On Mon, Oct 9, 2017 at 6:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Mon, Oct 9, 2017 at 10:01 AM, Paul Barker <pbarker@toganlabs.com> wrote:
>> On Mon, Oct 9, 2017 at 5:49 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Mon, Oct 9, 2017 at 9:16 AM, Paul Barker <pbarker@toganlabs.com> wrote:
>>>> On Mon, Oct 9, 2017 at 5:04 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>> On Mon, Oct 9, 2017 at 6:15 AM, Paul Barker <pbarker@toganlabs.com> wrote:
>>>>>>
>>>>>> I'm looking at what I can use to determine if sse2 is supported for a
>>>>>> given machine/tune.
>>>>>>
>>>>>> In TUNE_FEATURES I could check for "core2" or "corei7" based on what's
>>>>>> in oe-core, but not sure this will cover tunings which might be
>>>>>> defined in other layers.
>>>>>>
>>>>>> Alternatively I could check TUNE_CCARGS for "-msse2" or later but that
>>>>>> feels dirty.
>>>>>>
>>>>>> Any suggestions on this?
>>>>>>
>>>
>>> Perhaps inverse is easier, meaning, set 387 for i586, i486 and i386
>>> and leave the
>>> defaults as it is for other variants
>>
>> Sadly that won't cover it. We'd also need to cover Pentium variants
>> pre-Pentium4 and early AMD variants. It's SSE2 which is needed not the
>> original SSE instructions.
>>
>
> Does testing X86ARCH32 work?

Sadly not. "tune-core2.inc" sets this to "i686" which would indicate
no SSE2 support, however the core2 series does support SSE2. So we
can't base the decision on the value of this variable.

-- 
Paul Barker
Togán Labs Ltd

Re: Illegal instruction when running go binaries in qemux86

[Paul Barker]

On Mon, Oct 9, 2017 at 6:28 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 10/9/17 12:11 PM, Andre McCurdy wrote:
>> On Mon, Oct 9, 2017 at 10:01 AM, Paul Barker <pbarker@toganlabs.com> wrote:
>>> On Mon, Oct 9, 2017 at 5:49 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>> On Mon, Oct 9, 2017 at 9:16 AM, Paul Barker <pbarker@toganlabs.com> wrote:
>>>>> On Mon, Oct 9, 2017 at 5:04 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>>> On Mon, Oct 9, 2017 at 6:15 AM, Paul Barker <pbarker@toganlabs.com> wrote:
>>>>>>>
>>>>>>> I'm looking at what I can use to determine if sse2 is supported for a
>>>>>>> given machine/tune.
>>>>>>>
>>>>>>> In TUNE_FEATURES I could check for "core2" or "corei7" based on what's
>>>>>>> in oe-core, but not sure this will cover tunings which might be
>>>>>>> defined in other layers.
>>>>>>>
>>>>>>> Alternatively I could check TUNE_CCARGS for "-msse2" or later but that
>>>>>>> feels dirty.
>>>>>>>
>>>>>>> Any suggestions on this?
>>>>>>>
>>>>
>>>> Perhaps inverse is easier, meaning, set 387 for i586, i486 and i386
>>>> and leave the
>>>> defaults as it is for other variants
>>>
>>> Sadly that won't cover it. We'd also need to cover Pentium variants
>>> pre-Pentium4 and early AMD variants. It's SSE2 which is needed not the
>>> original SSE instructions.
>>>
>
> This is why 'TUNE_FEATURES' was introduced.  If SSE2 (or something else) is need
> for proper configuration, then we should add a specific tune_feature and update
> the corresponding tunes.
>

Is it too late in the cycle for rocko to start adding "sse2" to
TUNE_FEATURES for relevant machine configurations and include files?
If it's still ok to make this change for rocko then this might be the
best path forward.

-- 
Paul Barker
Togán Labs Ltd

Re: Illegal instruction when running go binaries in qemux86

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

On 12 October 2017 at 13:07, Paul Barker <pbarker@toganlabs.com> wrote:

> Is it too late in the cycle for rocko to start adding "sse2" to
> TUNE_FEATURES for relevant machine configurations and include files?
> If it's still ok to make this change for rocko then this might be the
> best path forward.
>

As per the weekly status mail from Stephen, we've been frozen for weeks and
on Monday the 2.4RC2 build was done.  Unless QA finds something serious to
fix, I suspect that will be the 2.4 release.

Ross

[-- Attachment #2: Type: text/html, Size: 875 bytes --]

Re: Illegal instruction when running go binaries in qemux86

[Paul Barker]

On Thu, Oct 12, 2017 at 1:10 PM, Burton, Ross <ross.burton@intel.com> wrote:
> On 12 October 2017 at 13:07, Paul Barker <pbarker@toganlabs.com> wrote:
>>
>> Is it too late in the cycle for rocko to start adding "sse2" to
>> TUNE_FEATURES for relevant machine configurations and include files?
>> If it's still ok to make this change for rocko then this might be the
>> best path forward.
>
>
> As per the weekly status mail from Stephen, we've been frozen for weeks and
> on Monday the 2.4RC2 build was done.  Unless QA finds something serious to
> fix, I suspect that will be the 2.4 release.
>

I'm not expecting this to be fixed in time for 2.4.0 now. Can this
sort of change go into the rocko branch after release though?

What is broken, to my understanding, is all applications written in go
which perform floating point calculations on qemux86 or any other x86
target which doesn't support SSE2 instructions. We should find some
way of fixing this for the rocko branch after release. I'm just trying
to gauge what sort of solution will be acceptable before I spend time
implementing and testing.

-- 
Paul Barker
Togán Labs Ltd

Re: Illegal instruction when running go binaries in qemux86

[Andre McCurdy]

On Thu, Oct 12, 2017 at 5:16 AM, Paul Barker <pbarker@toganlabs.com> wrote:
> On Thu, Oct 12, 2017 at 1:10 PM, Burton, Ross <ross.burton@intel.com> wrote:
>> On 12 October 2017 at 13:07, Paul Barker <pbarker@toganlabs.com> wrote:
>>>
>>> Is it too late in the cycle for rocko to start adding "sse2" to
>>> TUNE_FEATURES for relevant machine configurations and include files?
>>> If it's still ok to make this change for rocko then this might be the
>>> best path forward.
>>
>> As per the weekly status mail from Stephen, we've been frozen for weeks and
>> on Monday the 2.4RC2 build was done.  Unless QA finds something serious to
>> fix, I suspect that will be the 2.4 release.
>
> I'm not expecting this to be fixed in time for 2.4.0 now. Can this
> sort of change go into the rocko branch after release though?
>
> What is broken, to my understanding, is all applications written in go
> which perform floating point calculations on qemux86 or any other x86
> target which doesn't support SSE2 instructions. We should find some
> way of fixing this for the rocko branch after release. I'm just trying
> to gauge what sort of solution will be acceptable before I spend time
> implementing and testing.

I guess for rocko we should go back to your original suggestion, ie
"should we just set GO386 = "387" so that it applies to all go
binaries and accept the slight loss of performance on x86 systems that
do support sse2 instructions?"