[OE-core] [PATCH 1/2] feature-arm-thumb.inc: Use thumb instruction by default if TUNE_FEATURES thumb

Martin Jansa martin.jansa at gmail.com
Sat Jan 11 23:19:48 UTC 2014


On Sat, Jan 11, 2014 at 05:16:27PM +0200, Andrei Gherzan wrote:
> On Sat, Jan 11, 2014 at 5:10 PM, Koen Kooi <koen at dominion.thruhere.net>wrote:
> 
> >
> > Op 11 jan. 2014, om 16:08 heeft Andrei Gherzan <andrei at gherzan.ro> het
> > volgende geschreven:
> >
> > > Avoid a confusion when including thumb in TUNE_FATURES. In the curent
> > behavior,
> > > if I include thumb in TUNE_FATURES, ARM_THUMB_M_OPT will be "-marm"
> > which makes
> > > no sense for me as a default behavior. Obviously I can change this by
> > using
> > > ARM_INSTRUCTION_SET = thumb. But this seems strange and confusing. So
> > let's do
> > > it the other way around: have thumb instructions as default when
> > TUNE_FATURES
> > > contains "thumb" and switch to "arm" instructions when
> > ARM_INSTRUCTION_SET is
> > > "arm".
> >
> > Since ARM_INSTRUCTION_SET is unset for most things this will change the
> > default, are you sure that this is what you want?
> >
> 
> I am aware of that but still, do you find it normal to add thumb as
> TUNE_FEATURE and get your self with arm instructions flag?
> And generally people adapt if changes make sense :)

With old behavior it was easier for DISTRO to have final say if it
supports thumb for MACHINEs with thumb in TUNE_FEATURES or not.

But with thumb-only MACHINE I see that this logic is going to be broken.

Should we introduce "arm" TUNE_FEATURE enabled in most MACHINEs (except
yours) and let feature-arm-thumb.inc respect that? (select "thumb" when
preferred or when there is no "arm" in TUNE_FEATUREs)?

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140112/ba1389d4/attachment-0002.sig>


More information about the Openembedded-core mailing list