[PATCH 1/2] go.bbclass: Export GOARM

[PATCH 1/2] go.bbclass: Export GOARM

[Mark Asselstine]

When building GO packages for ARM (v5, v6, v7) it is expected that the
GOARM env variable is set during the build. Not having GOARM exported
will result in GO binaries which can't be executed on the target
(terminate with segfault). Per https://github.com/golang/go/wiki/GoArm

We already have the logic in goarch.bbclass to determine the correct
value of GOARM (see GOARM_TARGET), but currently this is only used to
build go itself (go-cross_1.*.bb requires go-cross.inc --> export
GOARM = "${TARGET_GOARM}").

Here we export GOARM but we do it such that it is only exported if we
are building for 'arm' and only when recipes requiring/inheriting
go.bbclass are be used to build for the target.

Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
---

Richard,

MarkH and I were debating this one some. He was suggesting I add
'GOARM ?= ""' so as not to leave things undefined for non-arm target
builds. I however, like the behavior of this as submitted here as
non-arm target builds don't get polluted with a useless export in
their do_compile scripts and such. The question is as presented here
is the behavior deterministic?


meta/classes/go.bbclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index af331f8..72e2c29 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -8,6 +8,9 @@ GOROOT = "${STAGING_LIBDIR}/go"
 export GOROOT
 export GOROOT_FINAL = "${libdir}/go"
 
+GOARM_arm_class-target = "${TARGET_GOARM}"
+export GOARM
+
 DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go virtual/${TARGET_PREFIX}go-runtime"
 DEPENDS_GOLANG_class-native = "go-native"
 DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk virtual/${TARGET_PREFIX}go-runtime"
-- 
2.7.4

[PATCH 2/2] goarch.bbclass: set TARGET_GOARM as '7' for cortexa7

[Mark Asselstine]

The cortexa7 tunings use 'cortexa7' in their tunings and do not
include 'arm7' so we need to look for both when setting TARGET_GOARM.

Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
---
 meta/classes/goarch.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
index 39fea5e..077c967 100644
--- a/meta/classes/goarch.bbclass
+++ b/meta/classes/goarch.bbclass
@@ -74,7 +74,7 @@ def go_map_arch(a, d):
 def go_map_arm(a, f, d):
     import re
     if re.match('arm.*', a):
-        if 'armv7' in f:
+        if 'armv7' or 'cortexa7' in f:
             return '7'
         elif 'armv6' in f:
             return '6'
-- 
2.7.4

Re: [PATCH 1/2] go.bbclass: Export GOARM

[Christopher Larson]

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

How would bitbake respond to an ‘export’ line with the empty string? I.e.
can you do an actual conditional export the way we do conditional inherits,
so it still is only exported for arm, even if the value is set to the empty
string for others?

On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine <
mark.asselstine@windriver.com> wrote:

> When building GO packages for ARM (v5, v6, v7) it is expected that the
> GOARM env variable is set during the build. Not having GOARM exported
> will result in GO binaries which can't be executed on the target
> (terminate with segfault). Per https://github.com/golang/go/wiki/GoArm
>
> We already have the logic in goarch.bbclass to determine the correct
> value of GOARM (see GOARM_TARGET), but currently this is only used to
> build go itself (go-cross_1.*.bb requires go-cross.inc --> export
> GOARM = "${TARGET_GOARM}").
>
> Here we export GOARM but we do it such that it is only exported if we
> are building for 'arm' and only when recipes requiring/inheriting
> go.bbclass are be used to build for the target.
>
> Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
> ---
>
> Richard,
>
> MarkH and I were debating this one some. He was suggesting I add
> 'GOARM ?= ""' so as not to leave things undefined for non-arm target
> builds. I however, like the behavior of this as submitted here as
> non-arm target builds don't get polluted with a useless export in
> their do_compile scripts and such. The question is as presented here
> is the behavior deterministic?
>
>
> meta/classes/go.bbclass | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> index af331f8..72e2c29 100644
> --- a/meta/classes/go.bbclass
> +++ b/meta/classes/go.bbclass
> @@ -8,6 +8,9 @@ GOROOT = "${STAGING_LIBDIR}/go"
>  export GOROOT
>  export GOROOT_FINAL = "${libdir}/go"
>
> +GOARM_arm_class-target = "${TARGET_GOARM}"
> +export GOARM
> +
>  DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go
> virtual/${TARGET_PREFIX}go-runtime"
>  DEPENDS_GOLANG_class-native = "go-native"
>  DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk
> virtual/${TARGET_PREFIX}go-runtime"
> --
> 2.7.4
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>


-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics

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

Re: [PATCH 2/2] goarch.bbclass: set TARGET_GOARM as '7' for cortexa7

[Andre McCurdy]

On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine
<mark.asselstine@windriver.com> wrote:
>
> The cortexa7 tunings use 'cortexa7' in their tunings and do not
> include 'arm7' so we need to look for both when setting TARGET_GOARM.

Is cortexa7 a special case? Or will the same issue be there for
cortexa5, cortexa9, cortexa15, etc?

> Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
> ---
>  meta/classes/goarch.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
> index 39fea5e..077c967 100644
> --- a/meta/classes/goarch.bbclass
> +++ b/meta/classes/goarch.bbclass
> @@ -74,7 +74,7 @@ def go_map_arch(a, d):
>  def go_map_arm(a, f, d):
>      import re
>      if re.match('arm.*', a):
> -        if 'armv7' in f:
> +        if 'armv7' or 'cortexa7' in f:
>              return '7'
>          elif 'armv6' in f:
>              return '6'
> --
> 2.7.4
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 2/2] goarch.bbclass: set TARGET_GOARM as '7' for cortexa7

[Mark Asselstine]

On Wednesday, March 13, 2019 3:56:10 PM EDT Andre McCurdy wrote:
> On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine
> 
> <mark.asselstine@windriver.com> wrote:
> > The cortexa7 tunings use 'cortexa7' in their tunings and do not
> > include 'arm7' so we need to look for both when setting TARGET_GOARM.
> 
> Is cortexa7 a special case? Or will the same issue be there for
> cortexa5, cortexa9, cortexa15, etc?

Damn, was too fucused on the 1/2 patch of this RR I had my blinders on. Yes I 
should be looking for cortexa* as I believe they all fall in to the "7" 
bucket. I will redo this and after we sort out 1/2 I will send a v2.

MarkA

> 
> > Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
> > ---
> > 
> >  meta/classes/goarch.bbclass | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
> > index 39fea5e..077c967 100644
> > --- a/meta/classes/goarch.bbclass
> > +++ b/meta/classes/goarch.bbclass
> > 
> > @@ -74,7 +74,7 @@ def go_map_arch(a, d):
> >  def go_map_arm(a, f, d):
> >      import re
> > 
> >      if re.match('arm.*', a):
> > -        if 'armv7' in f:
> > 
> > +        if 'armv7' or 'cortexa7' in f:
> >              return '7'
> >          
> >          elif 'armv6' in f:
> >              return '6'
> > 
> > --
> > 2.7.4
> > 
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 1/2] go.bbclass: Export GOARM

[Mark Asselstine]

On Wednesday, March 13, 2019 3:40:18 PM EDT Christopher Larson wrote:
> How would bitbake respond to an ‘export’ line with the empty string? I.e.
> can you do an actual conditional export the way we do conditional inherits,
> so it still is only exported for arm, even if the value is set to the empty
> string for others?

I thought about doing this but did not attempt it. I will give it a go and see 
how it looks and works. I am still curious to hear from Richard on this as if 
it is deterministic it is the simplistic and easiest to read approach.

MarkA

> 
> On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine <
> 
> mark.asselstine@windriver.com> wrote:
> > When building GO packages for ARM (v5, v6, v7) it is expected that the
> > GOARM env variable is set during the build. Not having GOARM exported
> > will result in GO binaries which can't be executed on the target
> > (terminate with segfault). Per https://github.com/golang/go/wiki/GoArm
> > 
> > We already have the logic in goarch.bbclass to determine the correct
> > value of GOARM (see GOARM_TARGET), but currently this is only used to
> > build go itself (go-cross_1.*.bb requires go-cross.inc --> export
> > GOARM = "${TARGET_GOARM}").
> > 
> > Here we export GOARM but we do it such that it is only exported if we
> > are building for 'arm' and only when recipes requiring/inheriting
> > go.bbclass are be used to build for the target.
> > 
> > Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
> > ---
> > 
> > Richard,
> > 
> > MarkH and I were debating this one some. He was suggesting I add
> > 'GOARM ?= ""' so as not to leave things undefined for non-arm target
> > builds. I however, like the behavior of this as submitted here as
> > non-arm target builds don't get polluted with a useless export in
> > their do_compile scripts and such. The question is as presented here
> > is the behavior deterministic?
> > 
> > 
> > meta/classes/go.bbclass | 3 +++
> > 
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> > index af331f8..72e2c29 100644
> > --- a/meta/classes/go.bbclass
> > +++ b/meta/classes/go.bbclass
> > @@ -8,6 +8,9 @@ GOROOT = "${STAGING_LIBDIR}/go"
> > 
> >  export GOROOT
> >  export GOROOT_FINAL = "${libdir}/go"
> > 
> > +GOARM_arm_class-target = "${TARGET_GOARM}"
> > +export GOARM
> > +
> > 
> >  DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go
> > 
> > virtual/${TARGET_PREFIX}go-runtime"
> > 
> >  DEPENDS_GOLANG_class-native = "go-native"
> >  DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk
> > 
> > virtual/${TARGET_PREFIX}go-runtime"
> > --
> > 2.7.4
> > 
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 1/2] go.bbclass: Export GOARM

[Mark Asselstine]

On Wednesday, March 13, 2019 3:40:18 PM EDT Christopher Larson wrote:
> How would bitbake respond to an ‘export’ line with the empty string? I.e.
> can you do an actual conditional export the way we do conditional inherits,
> so it still is only exported for arm, even if the value is set to the empty
> string for others?

Unfortunately no. It is a parsing error.

I am working on alternatives and will hopefully have something out shortly.

MarkA

> 
> On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine <
> 
> mark.asselstine@windriver.com> wrote:
> > When building GO packages for ARM (v5, v6, v7) it is expected that the
> > GOARM env variable is set during the build. Not having GOARM exported
> > will result in GO binaries which can't be executed on the target
> > (terminate with segfault). Per https://github.com/golang/go/wiki/GoArm
> > 
> > We already have the logic in goarch.bbclass to determine the correct
> > value of GOARM (see GOARM_TARGET), but currently this is only used to
> > build go itself (go-cross_1.*.bb requires go-cross.inc --> export
> > GOARM = "${TARGET_GOARM}").
> > 
> > Here we export GOARM but we do it such that it is only exported if we
> > are building for 'arm' and only when recipes requiring/inheriting
> > go.bbclass are be used to build for the target.
> > 
> > Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
> > ---
> > 
> > Richard,
> > 
> > MarkH and I were debating this one some. He was suggesting I add
> > 'GOARM ?= ""' so as not to leave things undefined for non-arm target
> > builds. I however, like the behavior of this as submitted here as
> > non-arm target builds don't get polluted with a useless export in
> > their do_compile scripts and such. The question is as presented here
> > is the behavior deterministic?
> > 
> > 
> > meta/classes/go.bbclass | 3 +++
> > 
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> > index af331f8..72e2c29 100644
> > --- a/meta/classes/go.bbclass
> > +++ b/meta/classes/go.bbclass
> > @@ -8,6 +8,9 @@ GOROOT = "${STAGING_LIBDIR}/go"
> > 
> >  export GOROOT
> >  export GOROOT_FINAL = "${libdir}/go"
> > 
> > +GOARM_arm_class-target = "${TARGET_GOARM}"
> > +export GOARM
> > +
> > 
> >  DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go
> > 
> > virtual/${TARGET_PREFIX}go-runtime"
> > 
> >  DEPENDS_GOLANG_class-native = "go-native"
> >  DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk
> > 
> > virtual/${TARGET_PREFIX}go-runtime"
> > --
> > 2.7.4
> > 
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 1/2] go.bbclass: Export GOARM

[Christopher Larson]

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

Good to know, thanks. Possibly something to improve in bitbake at some
point in the future.

On Thu, Mar 14, 2019 at 11:32 AM Mark Asselstine <
mark.asselstine@windriver.com> wrote:

> On Wednesday, March 13, 2019 3:40:18 PM EDT Christopher Larson wrote:
> > How would bitbake respond to an ‘export’ line with the empty string? I.e.
> > can you do an actual conditional export the way we do conditional
> inherits,
> > so it still is only exported for arm, even if the value is set to the
> empty
> > string for others?
>
> Unfortunately no. It is a parsing error.
>
> I am working on alternatives and will hopefully have something out shortly.
>
> MarkA
>
> >
> > On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine <
> >
> > mark.asselstine@windriver.com> wrote:
> > > When building GO packages for ARM (v5, v6, v7) it is expected that the
> > > GOARM env variable is set during the build. Not having GOARM exported
> > > will result in GO binaries which can't be executed on the target
> > > (terminate with segfault). Per https://github.com/golang/go/wiki/GoArm
> > >
> > > We already have the logic in goarch.bbclass to determine the correct
> > > value of GOARM (see GOARM_TARGET), but currently this is only used to
> > > build go itself (go-cross_1.*.bb requires go-cross.inc --> export
> > > GOARM = "${TARGET_GOARM}").
> > >
> > > Here we export GOARM but we do it such that it is only exported if we
> > > are building for 'arm' and only when recipes requiring/inheriting
> > > go.bbclass are be used to build for the target.
> > >
> > > Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
> > > ---
> > >
> > > Richard,
> > >
> > > MarkH and I were debating this one some. He was suggesting I add
> > > 'GOARM ?= ""' so as not to leave things undefined for non-arm target
> > > builds. I however, like the behavior of this as submitted here as
> > > non-arm target builds don't get polluted with a useless export in
> > > their do_compile scripts and such. The question is as presented here
> > > is the behavior deterministic?
> > >
> > >
> > > meta/classes/go.bbclass | 3 +++
> > >
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> > > index af331f8..72e2c29 100644
> > > --- a/meta/classes/go.bbclass
> > > +++ b/meta/classes/go.bbclass
> > > @@ -8,6 +8,9 @@ GOROOT = "${STAGING_LIBDIR}/go"
> > >
> > >  export GOROOT
> > >  export GOROOT_FINAL = "${libdir}/go"
> > >
> > > +GOARM_arm_class-target = "${TARGET_GOARM}"
> > > +export GOARM
> > > +
> > >
> > >  DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go
> > >
> > > virtual/${TARGET_PREFIX}go-runtime"
> > >
> > >  DEPENDS_GOLANG_class-native = "go-native"
> > >  DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk
> > >
> > > virtual/${TARGET_PREFIX}go-runtime"
> > > --
> > > 2.7.4
> > >
> > > --
> > > _______________________________________________
> > > Openembedded-core mailing list
> > > Openembedded-core@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
>
>

-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics

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

Re: [PATCH 1/2] go.bbclass: Export GOARM

[Mark Asselstine]

On Thursday, March 14, 2019 2:44:35 PM EDT Christopher Larson wrote:
> Good to know, thanks. Possibly something to improve in bitbake at some
> point in the future.

This is what I am preparing to send out

---
GOARM[export] = "0"
GOARM_arm_class-target = "${TARGET_GOARM}"                                                                                                                                                                        
GOARM_arm_class-target[export] = "1"                                                                                                                                                                              
---

This should address Mark Hatle's concerns about GOARM being undefined/have 
deterministic behavior. For non-'arm' the export simply won't be present so it 
doesn't matter what GOARM is, for 'arm' we get what we want. And I get what I 
was aiming for, no environment pollution in run.do_compile and friends for 
non-'arm'.

I know it isn't really used elsewhere but I don't believe I am making any 
assumptions or using things in a way they shouldn't be used. At any rate I 
will send this out in 20 minutes or so and we'll see how it stands up.

MarkA

> 
> On Thu, Mar 14, 2019 at 11:32 AM Mark Asselstine <
> 
> mark.asselstine@windriver.com> wrote:
> > On Wednesday, March 13, 2019 3:40:18 PM EDT Christopher Larson wrote:
> > > How would bitbake respond to an ‘export’ line with the empty string?
> > > I.e.
> > > can you do an actual conditional export the way we do conditional
> > 
> > inherits,
> > 
> > > so it still is only exported for arm, even if the value is set to the
> > 
> > empty
> > 
> > > string for others?
> > 
> > Unfortunately no. It is a parsing error.
> > 
> > I am working on alternatives and will hopefully have something out
> > shortly.
> > 
> > MarkA
> > 
> > > On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine <
> > > 
> > > mark.asselstine@windriver.com> wrote:
> > > > When building GO packages for ARM (v5, v6, v7) it is expected that the
> > > > GOARM env variable is set during the build. Not having GOARM exported
> > > > will result in GO binaries which can't be executed on the target
> > > > (terminate with segfault). Per https://github.com/golang/go/wiki/GoArm
> > > > 
> > > > We already have the logic in goarch.bbclass to determine the correct
> > > > value of GOARM (see GOARM_TARGET), but currently this is only used to
> > > > build go itself (go-cross_1.*.bb requires go-cross.inc --> export
> > > > GOARM = "${TARGET_GOARM}").
> > > > 
> > > > Here we export GOARM but we do it such that it is only exported if we
> > > > are building for 'arm' and only when recipes requiring/inheriting
> > > > go.bbclass are be used to build for the target.
> > > > 
> > > > Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
> > > > ---
> > > > 
> > > > Richard,
> > > > 
> > > > MarkH and I were debating this one some. He was suggesting I add
> > > > 'GOARM ?= ""' so as not to leave things undefined for non-arm target
> > > > builds. I however, like the behavior of this as submitted here as
> > > > non-arm target builds don't get polluted with a useless export in
> > > > their do_compile scripts and such. The question is as presented here
> > > > is the behavior deterministic?
> > > > 
> > > > 
> > > > meta/classes/go.bbclass | 3 +++
> > > > 
> > > >  1 file changed, 3 insertions(+)
> > > > 
> > > > diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> > > > index af331f8..72e2c29 100644
> > > > --- a/meta/classes/go.bbclass
> > > > +++ b/meta/classes/go.bbclass
> > > > @@ -8,6 +8,9 @@ GOROOT = "${STAGING_LIBDIR}/go"
> > > > 
> > > >  export GOROOT
> > > >  export GOROOT_FINAL = "${libdir}/go"
> > > > 
> > > > +GOARM_arm_class-target = "${TARGET_GOARM}"
> > > > +export GOARM
> > > > +
> > > > 
> > > >  DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go
> > > > 
> > > > virtual/${TARGET_PREFIX}go-runtime"
> > > > 
> > > >  DEPENDS_GOLANG_class-native = "go-native"
> > > >  DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk
> > > > 
> > > > virtual/${TARGET_PREFIX}go-runtime"
> > > > --
> > > > 2.7.4
> > > > 
> > > > --
> > > > _______________________________________________
> > > > Openembedded-core mailing list
> > > > Openembedded-core@lists.openembedded.org
> > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 2/2] goarch.bbclass: set TARGET_GOARM as '7' for cortexa7

[Khem Raj]

On Wed, Mar 13, 2019 at 1:04 PM Mark Asselstine
<mark.asselstine@windriver.com> wrote:
>
> On Wednesday, March 13, 2019 3:56:10 PM EDT Andre McCurdy wrote:
> > On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine
> >
> > <mark.asselstine@windriver.com> wrote:
> > > The cortexa7 tunings use 'cortexa7' in their tunings and do not
> > > include 'arm7' so we need to look for both when setting TARGET_GOARM.
> >
> > Is cortexa7 a special case? Or will the same issue be there for
> > cortexa5, cortexa9, cortexa15, etc?
>
> Damn, was too fucused on the 1/2 patch of this RR I had my blinders on. Yes I
> should be looking for cortexa* as I believe they all fall in to the "7"

keep in mind we might have cortex-a53 etc which are v8

> bucket. I will redo this and after we sort out 1/2 I will send a v2.
>
> MarkA
>
> >
> > > Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
> > > ---
> > >
> > >  meta/classes/goarch.bbclass | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
> > > index 39fea5e..077c967 100644
> > > --- a/meta/classes/goarch.bbclass
> > > +++ b/meta/classes/goarch.bbclass
> > >
> > > @@ -74,7 +74,7 @@ def go_map_arch(a, d):
> > >  def go_map_arm(a, f, d):
> > >      import re
> > >
> > >      if re.match('arm.*', a):
> > > -        if 'armv7' in f:
> > >
> > > +        if 'armv7' or 'cortexa7' in f:
> > >              return '7'
> > >
> > >          elif 'armv6' in f:
> > >              return '6'
> > >
> > > --
> > > 2.7.4
> > >
> > > --
> > > _______________________________________________
> > > Openembedded-core mailing list
> > > Openembedded-core@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 2/2] goarch.bbclass: set TARGET_GOARM as '7' for cortexa7

[Mark Asselstine]

On Friday, March 15, 2019 1:42:55 AM EDT Khem Raj wrote:
> On Wed, Mar 13, 2019 at 1:04 PM Mark Asselstine
> 
> <mark.asselstine@windriver.com> wrote:
> > On Wednesday, March 13, 2019 3:56:10 PM EDT Andre McCurdy wrote:
> > > On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine
> > > 
> > > <mark.asselstine@windriver.com> wrote:
> > > > The cortexa7 tunings use 'cortexa7' in their tunings and do not
> > > > include 'arm7' so we need to look for both when setting TARGET_GOARM.
> > > 
> > > Is cortexa7 a special case? Or will the same issue be there for
> > > cortexa5, cortexa9, cortexa15, etc?
> > 
> > Damn, was too fucused on the 1/2 patch of this RR I had my blinders on.
> > Yes I should be looking for cortexa* as I believe they all fall in to the
> > "7"
> keep in mind we might have cortex-a53 etc which are v8

GOARM is not applicable to ARMv8, only v5, v6 and v7. I added the link to the 
documentation in the V2 along with additional notes to make this clear.

MarkA

> 
> > bucket. I will redo this and after we sort out 1/2 I will send a v2.
> > 
> > MarkA
> > 
> > > > Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
> > > > ---
> > > > 
> > > >  meta/classes/goarch.bbclass | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
> > > > index 39fea5e..077c967 100644
> > > > --- a/meta/classes/goarch.bbclass
> > > > +++ b/meta/classes/goarch.bbclass
> > > > 
> > > > @@ -74,7 +74,7 @@ def go_map_arch(a, d):
> > > >  def go_map_arm(a, f, d):
> > > >      import re
> > > > 
> > > >      if re.match('arm.*', a):
> > > > -        if 'armv7' in f:
> > > > 
> > > > +        if 'armv7' or 'cortexa7' in f:
> > > >              return '7'
> > > >          
> > > >          elif 'armv6' in f:
> > > >              return '6'
> > > > 
> > > > --
> > > > 2.7.4
> > > > 
> > > > --
> > > > _______________________________________________
> > > > Openembedded-core mailing list
> > > > Openembedded-core@lists.openembedded.org
> > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> > 
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core