diff mbox series

[scarthgap,14/21] lib/oe/go: document map_arch, and raise an error on unknown architecture

Message ID e6de433ccb2784581d6c775cce97f414ef9334b1.1763849517.git.steve@sakoman.com
State Accepted
Delegated to: Steve Sakoman
Headers show
Series [scarthgap,01/21] spdx30: fix cve status for patch files in VEX | expand

Commit Message

Steve Sakoman Nov. 22, 2025, 10:14 p.m. UTC 
From: Ross Burton <ross.burton@arm.com>

Add a comment explaining what this function does and where the values
come from.

If the architecture isn't know, instead of returning an empty string
which could fail mysteriously, raise a KeyError so it fails quickly.

(From OE-Core rev: 025414c16319b068df1cd757ad9a3c987a6b871d)

Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
 meta/lib/oe/go.py | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

Comments

Mark Hatle Nov. 27, 2025, 12:40 a.m. UTC | #1 
This patch breaks Microblaze for me.

Microblazeel is not in the list of course, but go doesn't support this architecture.

During parsing of various things, instead of the component not being available I 
now get many many lines similar to:

WARNING: <recipe>: Exception during build_dependencies for GOARCH
WARNING: <recipe>: Error during finalize of <multiconfig>
ERROR: ExpansionError during parsing <recipe>
bb.data_smart.ExceptionError: Failure expanding TARGET_GOARCH, expression was 
${go_map_arch(d.getVar('TARGET_ARCH'), d)} which triggered exception KeyError: 
'Cannot map architecture microblazeel'
The variable dependency chain for the failure is: TARGET_GOARCH -> GOARCH

(at which point parsing stops)

I see no obvious way here to add an architecture that OE/Poky does not support, 
which now makes this a hard error for any architecture not supported by the core 
of OE and/or go.  (in the case of microblaze, rust and go are likely to never be 
supported.  So there has to be a way for me to avoid the parse error in these 
cases.)

On 11/22/25 4:14 PM, Steve Sakoman wrote:
> From: Ross Burton <ross.burton@arm.com>
> 
> Add a comment explaining what this function does and where the values
> come from.
> 
> If the architecture isn't know, instead of returning an empty string
> which could fail mysteriously, raise a KeyError so it fails quickly.
> 
> (From OE-Core rev: 025414c16319b068df1cd757ad9a3c987a6b871d)
> 
> Signed-off-by: Ross Burton <ross.burton@arm.com>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> Signed-off-by: Peter Marko <peter.marko@siemens.com>
> Signed-off-by: Steve Sakoman <steve@sakoman.com>
> ---
>   meta/lib/oe/go.py | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/lib/oe/go.py b/meta/lib/oe/go.py
> index dfd957d157..4559dc63b2 100644
> --- a/meta/lib/oe/go.py
> +++ b/meta/lib/oe/go.py
> @@ -7,6 +7,10 @@
>   import re
>   
>   def map_arch(a):
> +    """
> +    Map our architecture names to Go's GOARCH names.
> +    See https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go for the complete list.
> +    """
>       if re.match('i.86', a):
>           return '386'
>       elif a == 'x86_64':
> @@ -31,4 +35,4 @@ def map_arch(a):
>           return 'riscv64'
>       elif a == 'loongarch64':
>           return 'loong64'
> -    return ''
> +    raise KeyError(f"Cannot map architecture {a}")
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#226712): https://lists.openembedded.org/g/openembedded-core/message/226712
> Mute This Topic: https://lists.openembedded.org/mt/116430143/3616948
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [mark.hatle@kernel.crashing.org]
> -=-=-=-=-=-=-=-=-=-=-=-
>
Mark Hatle Nov. 27, 2025, 1:02 a.m. UTC | #2 
I have a possible workaround, for microblaze, for this.

Basically it's to force include a class that does:

python __anonymous() {
     if bb.data.inherits_class('goarch', d):
         if d.getVar('TARGET_ARCH') in ['microblaze', 'microblazeel', 
'microblazeeb']:
             raise bb.parse.SkipRecipe("Go does not support microblaze.")
}

On 11/26/25 6:40 PM, Mark Hatle wrote:
> This patch breaks Microblaze for me.
> 
> Microblazeel is not in the list of course, but go doesn't support this architecture.
> 
> During parsing of various things, instead of the component not being available I
> now get many many lines similar to:
> 
> WARNING: <recipe>: Exception during build_dependencies for GOARCH
> WARNING: <recipe>: Error during finalize of <multiconfig>
> ERROR: ExpansionError during parsing <recipe>
> bb.data_smart.ExceptionError: Failure expanding TARGET_GOARCH, expression was
> ${go_map_arch(d.getVar('TARGET_ARCH'), d)} which triggered exception KeyError:
> 'Cannot map architecture microblazeel'
> The variable dependency chain for the failure is: TARGET_GOARCH -> GOARCH
> 
> (at which point parsing stops)
> 
> I see no obvious way here to add an architecture that OE/Poky does not support,
> which now makes this a hard error for any architecture not supported by the core
> of OE and/or go.  (in the case of microblaze, rust and go are likely to never be
> supported.  So there has to be a way for me to avoid the parse error in these
> cases.)
> 
> On 11/22/25 4:14 PM, Steve Sakoman wrote:
>> From: Ross Burton <ross.burton@arm.com>
>>
>> Add a comment explaining what this function does and where the values
>> come from.
>>
>> If the architecture isn't know, instead of returning an empty string
>> which could fail mysteriously, raise a KeyError so it fails quickly.
>>
>> (From OE-Core rev: 025414c16319b068df1cd757ad9a3c987a6b871d)
>>
>> Signed-off-by: Ross Burton <ross.burton@arm.com>
>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>> Signed-off-by: Peter Marko <peter.marko@siemens.com>
>> Signed-off-by: Steve Sakoman <steve@sakoman.com>
>> ---
>>    meta/lib/oe/go.py | 6 +++++-
>>    1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta/lib/oe/go.py b/meta/lib/oe/go.py
>> index dfd957d157..4559dc63b2 100644
>> --- a/meta/lib/oe/go.py
>> +++ b/meta/lib/oe/go.py
>> @@ -7,6 +7,10 @@
>>    import re
>>    
>>    def map_arch(a):
>> +    """
>> +    Map our architecture names to Go's GOARCH names.
>> +    See https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go for the complete list.
>> +    """
>>        if re.match('i.86', a):
>>            return '386'
>>        elif a == 'x86_64':
>> @@ -31,4 +35,4 @@ def map_arch(a):
>>            return 'riscv64'
>>        elif a == 'loongarch64':
>>            return 'loong64'
>> -    return ''
>> +    raise KeyError(f"Cannot map architecture {a}")
>>
>>
>>
>>
>>
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> View/Reply Online (#226817): https://lists.openembedded.org/g/openembedded-core/message/226817
>> Mute This Topic: https://lists.openembedded.org/mt/116430143/3616948
>> Group Owner: openembedded-core+owner@lists.openembedded.org
>> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [mark.hatle@kernel.crashing.org]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
Peter Kjellerstedt Nov. 27, 2025, 4:45 a.m. UTC | #3 
> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> On Behalf Of Mark Hatle
> Sent: den 27 november 2025 02:02
> To: Steve Sakoman <steve@sakoman.com>; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core][scarthgap 14/21] lib/oe/go: document map_arch, and raise an error on unknown architecture
> 
> I have a possible workaround, for microblaze, for this.
> 
> Basically it's to force include a class that does:
> 
> python __anonymous() {
>      if bb.data.inherits_class('goarch', d):
>          if d.getVar('TARGET_ARCH') in ['microblaze', 'microblazeel', 'microblazeeb']:
>              raise bb.parse.SkipRecipe("Go does not support microblaze.")
> }

What if you make the map_arch() function raise bb.parse.SkipRecipe rather 
than KeyError? Wouldn't that achieve the same without having to hardcode 
a solution for each architecture that is not supported by Go?

//Peter

> On 11/26/25 6:40 PM, Mark Hatle wrote:
> > This patch breaks Microblaze for me.
> >
> > Microblazeel is not in the list of course, but go doesn't support this architecture.
> >
> > During parsing of various things, instead of the component not being available I
> > now get many many lines similar to:
> >
> > WARNING: <recipe>: Exception during build_dependencies for GOARCH
> > WARNING: <recipe>: Error during finalize of <multiconfig>
> > ERROR: ExpansionError during parsing <recipe>
> > bb.data_smart.ExceptionError: Failure expanding TARGET_GOARCH, expression was
> > ${go_map_arch(d.getVar('TARGET_ARCH'), d)} which triggered exception KeyError:
> > 'Cannot map architecture microblazeel'
> > The variable dependency chain for the failure is: TARGET_GOARCH -> GOARCH
> >
> > (at which point parsing stops)
> >
> > I see no obvious way here to add an architecture that OE/Poky does not support,
> > which now makes this a hard error for any architecture not supported by the core
> > of OE and/or go.  (in the case of microblaze, rust and go are likely to never be
> > supported.  So there has to be a way for me to avoid the parse error in these
> > cases.)
> >
> > On 11/22/25 4:14 PM, Steve Sakoman wrote:
> >> From: Ross Burton <ross.burton@arm.com>
> >>
> >> Add a comment explaining what this function does and where the values
> >> come from.
> >>
> >> If the architecture isn't know, instead of returning an empty string
> >> which could fail mysteriously, raise a KeyError so it fails quickly.
> >>
> >> (From OE-Core rev: 025414c16319b068df1cd757ad9a3c987a6b871d)
> >>
> >> Signed-off-by: Ross Burton <ross.burton@arm.com>
> >> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> >> Signed-off-by: Peter Marko <peter.marko@siemens.com>
> >> Signed-off-by: Steve Sakoman <steve@sakoman.com>
> >> ---
> >>    meta/lib/oe/go.py | 6 +++++-
> >>    1 file changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/meta/lib/oe/go.py b/meta/lib/oe/go.py
> >> index dfd957d157..4559dc63b2 100644
> >> --- a/meta/lib/oe/go.py
> >> +++ b/meta/lib/oe/go.py
> >> @@ -7,6 +7,10 @@
> >>    import re
> >>
> >>    def map_arch(a):
> >> +    """
> >> +    Map our architecture names to Go's GOARCH names.
> >> +    See https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go for the complete list.
> >> +    """
> >>        if re.match('i.86', a):
> >>            return '386'
> >>        elif a == 'x86_64':
> >> @@ -31,4 +35,4 @@ def map_arch(a):
> >>            return 'riscv64'
> >>        elif a == 'loongarch64':
> >>            return 'loong64'
> >> -    return ''
> >> +    raise KeyError(f"Cannot map architecture {a}")
Peter Marko Nov. 27, 2025, 7 a.m. UTC | #4 
> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-
> core@lists.openembedded.org> On Behalf Of Mark Hatle
> Sent: Thursday, November 27, 2025 2:02
> To: Steve Sakoman <steve@sakoman.com>; openembedded-
> core@lists.openembedded.org
> Subject: Re: [OE-core][scarthgap 14/21] lib/oe/go: document map_arch, and raise
> an error on unknown architecture
> 
> I have a possible workaround, for microblaze, for this.
> 
> Basically it's to force include a class that does:
> 
> python __anonymous() {
>      if bb.data.inherits_class('goarch', d):
>          if d.getVar('TARGET_ARCH') in ['microblaze', 'microblazeel',
> 'microblazeeb']:
>              raise bb.parse.SkipRecipe("Go does not support microblaze.")
> }
> 
> On 11/26/25 6:40 PM, Mark Hatle wrote:
> > This patch breaks Microblaze for me.
> >
> > Microblazeel is not in the list of course, but go doesn't support this architecture.
> >
> > During parsing of various things, instead of the component not being available I
> > now get many many lines similar to:
> >
> > WARNING: <recipe>: Exception during build_dependencies for GOARCH
> > WARNING: <recipe>: Error during finalize of <multiconfig>
> > ERROR: ExpansionError during parsing <recipe>
> > bb.data_smart.ExceptionError: Failure expanding TARGET_GOARCH,
> expression was
> > ${go_map_arch(d.getVar('TARGET_ARCH'), d)} which triggered exception
> KeyError:
> > 'Cannot map architecture microblazeel'
> > The variable dependency chain for the failure is: TARGET_GOARCH -> GOARCH
> >
> > (at which point parsing stops)
> >
> > I see no obvious way here to add an architecture that OE/Poky does not
> support,
> > which now makes this a hard error for any architecture not supported by the core
> > of OE and/or go.  (in the case of microblaze, rust and go are likely to never be
> > supported.  So there has to be a way for me to avoid the parse error in these
> > cases.)

OK, that's unfortunate.

However this is something that needed a review when pushed to master branch half a year ago.
This backport then just means you see it half a year ahead of migrating to new LTS release.

Possibly submit a revert or other adaptation to master branch and we can backport it then to scarthgap .

Peter

> >
> > On 11/22/25 4:14 PM, Steve Sakoman wrote:
> >> From: Ross Burton <ross.burton@arm.com>
> >>
> >> Add a comment explaining what this function does and where the values
> >> come from.
> >>
> >> If the architecture isn't know, instead of returning an empty string
> >> which could fail mysteriously, raise a KeyError so it fails quickly.
> >>
> >> (From OE-Core rev: 025414c16319b068df1cd757ad9a3c987a6b871d)
> >>
> >> Signed-off-by: Ross Burton <ross.burton@arm.com>
> >> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> >> Signed-off-by: Peter Marko <peter.marko@siemens.com>
> >> Signed-off-by: Steve Sakoman <steve@sakoman.com>
> >> ---
> >>    meta/lib/oe/go.py | 6 +++++-
> >>    1 file changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/meta/lib/oe/go.py b/meta/lib/oe/go.py
> >> index dfd957d157..4559dc63b2 100644
> >> --- a/meta/lib/oe/go.py
> >> +++ b/meta/lib/oe/go.py
> >> @@ -7,6 +7,10 @@
> >>    import re
> >>
> >>    def map_arch(a):
> >> +    """
> >> +    Map our architecture names to Go's GOARCH names.
> >> +    See https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go
> for the complete list.
> >> +    """
> >>        if re.match('i.86', a):
> >>            return '386'
> >>        elif a == 'x86_64':
> >> @@ -31,4 +35,4 @@ def map_arch(a):
> >>            return 'riscv64'
> >>        elif a == 'loongarch64':
> >>            return 'loong64'
> >> -    return ''
> >> +    raise KeyError(f"Cannot map architecture {a}")
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
Mark Hatle Nov. 27, 2025, 3:49 p.m. UTC | #5 
On 11/26/25 10:45 PM, Peter Kjellerstedt via lists.openembedded.org wrote:
>> -----Original Message-----
>> From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> On Behalf Of Mark Hatle
>> Sent: den 27 november 2025 02:02
>> To: Steve Sakoman <steve@sakoman.com>; openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core][scarthgap 14/21] lib/oe/go: document map_arch, and raise an error on unknown architecture
>>
>> I have a possible workaround, for microblaze, for this.
>>
>> Basically it's to force include a class that does:
>>
>> python __anonymous() {
>>       if bb.data.inherits_class('goarch', d):
>>           if d.getVar('TARGET_ARCH') in ['microblaze', 'microblazeel', 'microblazeeb']:
>>               raise bb.parse.SkipRecipe("Go does not support microblaze.")
>> }
> 
> What if you make the map_arch() function raise bb.parse.SkipRecipe rather
> than KeyError? Wouldn't that achieve the same without having to hardcode
> a solution for each architecture that is not supported by Go?

_I_ can't make map_arch raise skiprecipe because it's part of oe-core and there 
is no easy way to override it in a layer.

But with that, said, raising an exception in map_arch() of KeyError really feels 
anti-social.  Changing THAT exception to a SkipRecipe would make a lot more 
sense and prevent anyone from using go that wasn't supported.

Alternatively the caller of map_arch could catch the key error and raise the 
skiprecipe with an appropriate message as well.

I have a similar chunk like that anonymous python for rust for a similar reason. 
  That might be another candidate to do some sort of automatic raise if it's 
unsupported.

In any case, I think there are really two issues here.

1) Raising KeyError is antisocial to architectures that are out of tree and 
don't support go.

2) There should be a way for out of tree architectures to _easily_ add 
themselves to the arch list, should they be supported by go.

--Mark

> //Peter
> 
>> On 11/26/25 6:40 PM, Mark Hatle wrote:
>>> This patch breaks Microblaze for me.
>>>
>>> Microblazeel is not in the list of course, but go doesn't support this architecture.
>>>
>>> During parsing of various things, instead of the component not being available I
>>> now get many many lines similar to:
>>>
>>> WARNING: <recipe>: Exception during build_dependencies for GOARCH
>>> WARNING: <recipe>: Error during finalize of <multiconfig>
>>> ERROR: ExpansionError during parsing <recipe>
>>> bb.data_smart.ExceptionError: Failure expanding TARGET_GOARCH, expression was
>>> ${go_map_arch(d.getVar('TARGET_ARCH'), d)} which triggered exception KeyError:
>>> 'Cannot map architecture microblazeel'
>>> The variable dependency chain for the failure is: TARGET_GOARCH -> GOARCH
>>>
>>> (at which point parsing stops)
>>>
>>> I see no obvious way here to add an architecture that OE/Poky does not support,
>>> which now makes this a hard error for any architecture not supported by the core
>>> of OE and/or go.  (in the case of microblaze, rust and go are likely to never be
>>> supported.  So there has to be a way for me to avoid the parse error in these
>>> cases.)
>>>
>>> On 11/22/25 4:14 PM, Steve Sakoman wrote:
>>>> From: Ross Burton <ross.burton@arm.com>
>>>>
>>>> Add a comment explaining what this function does and where the values
>>>> come from.
>>>>
>>>> If the architecture isn't know, instead of returning an empty string
>>>> which could fail mysteriously, raise a KeyError so it fails quickly.
>>>>
>>>> (From OE-Core rev: 025414c16319b068df1cd757ad9a3c987a6b871d)
>>>>
>>>> Signed-off-by: Ross Burton <ross.burton@arm.com>
>>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>>> Signed-off-by: Peter Marko <peter.marko@siemens.com>
>>>> Signed-off-by: Steve Sakoman <steve@sakoman.com>
>>>> ---
>>>>     meta/lib/oe/go.py | 6 +++++-
>>>>     1 file changed, 5 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/meta/lib/oe/go.py b/meta/lib/oe/go.py
>>>> index dfd957d157..4559dc63b2 100644
>>>> --- a/meta/lib/oe/go.py
>>>> +++ b/meta/lib/oe/go.py
>>>> @@ -7,6 +7,10 @@
>>>>     import re
>>>>
>>>>     def map_arch(a):
>>>> +    """
>>>> +    Map our architecture names to Go's GOARCH names.
>>>> +    See https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go for the complete list.
>>>> +    """
>>>>         if re.match('i.86', a):
>>>>             return '386'
>>>>         elif a == 'x86_64':
>>>> @@ -31,4 +35,4 @@ def map_arch(a):
>>>>             return 'riscv64'
>>>>         elif a == 'loongarch64':
>>>>             return 'loong64'
>>>> -    return ''
>>>> +    raise KeyError(f"Cannot map architecture {a}")
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#226826): https://lists.openembedded.org/g/openembedded-core/message/226826
> Mute This Topic: https://lists.openembedded.org/mt/116430143/3616948
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [mark.hatle@kernel.crashing.org]
> -=-=-=-=-=-=-=-=-=-=-=-
>
Mark Hatle Nov. 27, 2025, 3:51 p.m. UTC | #6 
On 11/27/25 1:00 AM, Peter Marko via lists.openembedded.org wrote:
> 
> 
>> -----Original Message-----
>> From: openembedded-core@lists.openembedded.org <openembedded-
>> core@lists.openembedded.org> On Behalf Of Mark Hatle
>> Sent: Thursday, November 27, 2025 2:02
>> To: Steve Sakoman <steve@sakoman.com>; openembedded-
>> core@lists.openembedded.org
>> Subject: Re: [OE-core][scarthgap 14/21] lib/oe/go: document map_arch, and raise
>> an error on unknown architecture
>>
>> I have a possible workaround, for microblaze, for this.
>>
>> Basically it's to force include a class that does:
>>
>> python __anonymous() {
>>       if bb.data.inherits_class('goarch', d):
>>           if d.getVar('TARGET_ARCH') in ['microblaze', 'microblazeel',
>> 'microblazeeb']:
>>               raise bb.parse.SkipRecipe("Go does not support microblaze.")
>> }
>>
>> On 11/26/25 6:40 PM, Mark Hatle wrote:
>>> This patch breaks Microblaze for me.
>>>
>>> Microblazeel is not in the list of course, but go doesn't support this architecture.
>>>
>>> During parsing of various things, instead of the component not being available I
>>> now get many many lines similar to:
>>>
>>> WARNING: <recipe>: Exception during build_dependencies for GOARCH
>>> WARNING: <recipe>: Error during finalize of <multiconfig>
>>> ERROR: ExpansionError during parsing <recipe>
>>> bb.data_smart.ExceptionError: Failure expanding TARGET_GOARCH,
>> expression was
>>> ${go_map_arch(d.getVar('TARGET_ARCH'), d)} which triggered exception
>> KeyError:
>>> 'Cannot map architecture microblazeel'
>>> The variable dependency chain for the failure is: TARGET_GOARCH -> GOARCH
>>>
>>> (at which point parsing stops)
>>>
>>> I see no obvious way here to add an architecture that OE/Poky does not
>> support,
>>> which now makes this a hard error for any architecture not supported by the core
>>> of OE and/or go.  (in the case of microblaze, rust and go are likely to never be
>>> supported.  So there has to be a way for me to avoid the parse error in these
>>> cases.)
> 
> OK, that's unfortunate.
> 
> However this is something that needed a review when pushed to master branch half a year ago.
> This backport then just means you see it half a year ahead of migrating to new LTS release.
> 
> Possibly submit a revert or other adaptation to master branch and we can backport it then to scarthgap .

I do NOT believe this should be reverted in master.  Master is different then 
scarthgap, and per my other reply to Peter Kjellerstedt I think it should be 
adjusted.  I'm willing to try to suggest the adjustments to master.

It's scarthgap that I think this should be reverted.  It's a change in behavior 
from prior scarthgap and absolutely broke my existing (functional) layer.  With 
that said, I have a 'workaround' for it, but it's going to take me time to QA 
everything and get it in for my scarthgap users.

My objection is to changing system behavior in the LTS, nothing more in this case.

--Mark

> Peter
> 
>>>
>>> On 11/22/25 4:14 PM, Steve Sakoman wrote:
>>>> From: Ross Burton <ross.burton@arm.com>
>>>>
>>>> Add a comment explaining what this function does and where the values
>>>> come from.
>>>>
>>>> If the architecture isn't know, instead of returning an empty string
>>>> which could fail mysteriously, raise a KeyError so it fails quickly.
>>>>
>>>> (From OE-Core rev: 025414c16319b068df1cd757ad9a3c987a6b871d)
>>>>
>>>> Signed-off-by: Ross Burton <ross.burton@arm.com>
>>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>>>> Signed-off-by: Peter Marko <peter.marko@siemens.com>
>>>> Signed-off-by: Steve Sakoman <steve@sakoman.com>
>>>> ---
>>>>     meta/lib/oe/go.py | 6 +++++-
>>>>     1 file changed, 5 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/meta/lib/oe/go.py b/meta/lib/oe/go.py
>>>> index dfd957d157..4559dc63b2 100644
>>>> --- a/meta/lib/oe/go.py
>>>> +++ b/meta/lib/oe/go.py
>>>> @@ -7,6 +7,10 @@
>>>>     import re
>>>>
>>>>     def map_arch(a):
>>>> +    """
>>>> +    Map our architecture names to Go's GOARCH names.
>>>> +    See https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go
>> for the complete list.
>>>> +    """
>>>>         if re.match('i.86', a):
>>>>             return '386'
>>>>         elif a == 'x86_64':
>>>> @@ -31,4 +35,4 @@ def map_arch(a):
>>>>             return 'riscv64'
>>>>         elif a == 'loongarch64':
>>>>             return 'loong64'
>>>> -    return ''
>>>> +    raise KeyError(f"Cannot map architecture {a}")
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>> Links: You receive all messages sent to this group.
>>>> View/Reply Online (#226827): https://lists.openembedded.org/g/openembedded-core/message/226827
>>>> Mute This Topic: https://lists.openembedded.org/mt/116430143/3616948
>>>> Group Owner: openembedded-core+owner@lists.openembedded.org
>>>> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [mark.hatle@kernel.crashing.org]
>>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>>
Peter Marko Nov. 27, 2025, 4:08 p.m. UTC | #7 
> -----Original Message-----
> From: Mark Hatle <mark.hatle@kernel.crashing.org>
> Sent: Thursday, November 27, 2025 16:52
> To: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>; Steve
> Sakoman <steve@sakoman.com>; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core][scarthgap 14/21] lib/oe/go: document map_arch, and raise
> an error on unknown architecture
> 
> 
> 
> On 11/27/25 1:00 AM, Peter Marko via lists.openembedded.org wrote:
> >
> >
> >> -----Original Message-----
> >> From: openembedded-core@lists.openembedded.org <openembedded-
> >> core@lists.openembedded.org> On Behalf Of Mark Hatle
> >> Sent: Thursday, November 27, 2025 2:02
> >> To: Steve Sakoman <steve@sakoman.com>; openembedded-
> >> core@lists.openembedded.org
> >> Subject: Re: [OE-core][scarthgap 14/21] lib/oe/go: document map_arch, and
> raise
> >> an error on unknown architecture
> >>
> >> I have a possible workaround, for microblaze, for this.
> >>
> >> Basically it's to force include a class that does:
> >>
> >> python __anonymous() {
> >>       if bb.data.inherits_class('goarch', d):
> >>           if d.getVar('TARGET_ARCH') in ['microblaze', 'microblazeel',
> >> 'microblazeeb']:
> >>               raise bb.parse.SkipRecipe("Go does not support microblaze.")
> >> }
> >>
> >> On 11/26/25 6:40 PM, Mark Hatle wrote:
> >>> This patch breaks Microblaze for me.
> >>>
> >>> Microblazeel is not in the list of course, but go doesn't support this
> architecture.
> >>>
> >>> During parsing of various things, instead of the component not being
> available I
> >>> now get many many lines similar to:
> >>>
> >>> WARNING: <recipe>: Exception during build_dependencies for GOARCH
> >>> WARNING: <recipe>: Error during finalize of <multiconfig>
> >>> ERROR: ExpansionError during parsing <recipe>
> >>> bb.data_smart.ExceptionError: Failure expanding TARGET_GOARCH,
> >> expression was
> >>> ${go_map_arch(d.getVar('TARGET_ARCH'), d)} which triggered exception
> >> KeyError:
> >>> 'Cannot map architecture microblazeel'
> >>> The variable dependency chain for the failure is: TARGET_GOARCH ->
> GOARCH
> >>>
> >>> (at which point parsing stops)
> >>>
> >>> I see no obvious way here to add an architecture that OE/Poky does not
> >> support,
> >>> which now makes this a hard error for any architecture not supported by the
> core
> >>> of OE and/or go.  (in the case of microblaze, rust and go are likely to never
> be
> >>> supported.  So there has to be a way for me to avoid the parse error in these
> >>> cases.)
> >
> > OK, that's unfortunate.
> >
> > However this is something that needed a review when pushed to master branch
> half a year ago.
> > This backport then just means you see it half a year ahead of migrating to new
> LTS release.
> >
> > Possibly submit a revert or other adaptation to master branch and we can
> backport it then to scarthgap .
> 
> I do NOT believe this should be reverted in master.  Master is different then
> scarthgap, and per my other reply to Peter Kjellerstedt I think it should be
> adjusted.  I'm willing to try to suggest the adjustments to master.
> 
> It's scarthgap that I think this should be reverted.  It's a change in behavior
> from prior scarthgap and absolutely broke my existing (functional) layer.  With
> that said, I have a 'workaround' for it, but it's going to take me time to QA
> everything and get it in for my scarthgap users.
> 
> My objection is to changing system behavior in the LTS, nothing more in this
> case.

OK, no problem, I don’t insist on this commit to be present in scarthgap, I need the other ones from tat series for proper golang testing.
Feel free to send a revert commit.

Peter

> 
> --Mark
> 
> > Peter
> >
> >>>
> >>> On 11/22/25 4:14 PM, Steve Sakoman wrote:
> >>>> From: Ross Burton <ross.burton@arm.com>
> >>>>
> >>>> Add a comment explaining what this function does and where the values
> >>>> come from.
> >>>>
> >>>> If the architecture isn't know, instead of returning an empty string
> >>>> which could fail mysteriously, raise a KeyError so it fails quickly.
> >>>>
> >>>> (From OE-Core rev: 025414c16319b068df1cd757ad9a3c987a6b871d)
> >>>>
> >>>> Signed-off-by: Ross Burton <ross.burton@arm.com>
> >>>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> >>>> Signed-off-by: Peter Marko <peter.marko@siemens.com>
> >>>> Signed-off-by: Steve Sakoman <steve@sakoman.com>
> >>>> ---
> >>>>     meta/lib/oe/go.py | 6 +++++-
> >>>>     1 file changed, 5 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/meta/lib/oe/go.py b/meta/lib/oe/go.py
> >>>> index dfd957d157..4559dc63b2 100644
> >>>> --- a/meta/lib/oe/go.py
> >>>> +++ b/meta/lib/oe/go.py
> >>>> @@ -7,6 +7,10 @@
> >>>>     import re
> >>>>
> >>>>     def map_arch(a):
> >>>> +    """
> >>>> +    Map our architecture names to Go's GOARCH names.
> >>>> +    See
> https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go
> >> for the complete list.
> >>>> +    """
> >>>>         if re.match('i.86', a):
> >>>>             return '386'
> >>>>         elif a == 'x86_64':
> >>>> @@ -31,4 +35,4 @@ def map_arch(a):
> >>>>             return 'riscv64'
> >>>>         elif a == 'loongarch64':
> >>>>             return 'loong64'
> >>>> -    return ''
> >>>> +    raise KeyError(f"Cannot map architecture {a}")
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> -=-=-=-=-=-=-=-=-=-=-=-
> >>>> Links: You receive all messages sent to this group.
> >>>> View/Reply Online (#226827):
> https://lists.openembedded.org/g/openembedded-core/message/226827
> >>>> Mute This Topic: https://lists.openembedded.org/mt/116430143/3616948
> >>>> Group Owner: openembedded-core+owner@lists.openembedded.org
> >>>> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
> [mark.hatle@kernel.crashing.org]
> >>>> -=-=-=-=-=-=-=-=-=-=-=-
> >>>>
diff mbox series

Patch

diff --git a/meta/lib/oe/go.py b/meta/lib/oe/go.py
index dfd957d157..4559dc63b2 100644
--- a/meta/lib/oe/go.py
+++ b/meta/lib/oe/go.py
@@ -7,6 +7,10 @@ 
 import re
 
 def map_arch(a):
+    """
+    Map our architecture names to Go's GOARCH names.
+    See https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go for the complete list.
+    """
     if re.match('i.86', a):
         return '386'
     elif a == 'x86_64':
@@ -31,4 +35,4 @@  def map_arch(a):
         return 'riscv64'
     elif a == 'loongarch64':
         return 'loong64'
-    return ''
+    raise KeyError(f"Cannot map architecture {a}")