| Message ID | 1458164602-16983-5-git-send-email-thomas.petazzoni@free-electrons.com |
|---|---|
| State | Superseded |
| Headers | show |
On 03/16/16 22:43, Thomas Petazzoni wrote: > From: Paul Enman <paul.enman@gmail.com> > > Until now, when thumb was selected with threads, we were forcing ARM > mode to be used, to workaround some problems building uClibc with > threads in Thumb mode. Also, we were never enabling Thumb mode in > uClibc when Thumb2 was selected in the configuration. > > Therefore, this commit updates the uclibc.mk logic to: > > - Force ARM mode only when gcc 4.7 or 4.8 is selected with Thumb1 and > threads. We also explicitly disable COMPILE_IN_THUMB_MODE when we > fall in this situation. With newer gcc versions, starting 4.9, this > problem is fixed and we can build uClibc in Thumb1 mode. > > - Enable COMPILE_IN_THUMB_MODE when Thumb1 or Thumb2 is selected. We > need to disable context functions since they don't build in Thumb > mode. > > - Disable COMPILE_IN_THUMB_MODE explicitly otherwise. > > This allows to build a Thumb2 toolchain on ARMv7-M for example. Principle looks OK to me, but it will of course have to be reworked if you follow my suggestion os removing BR2_ARM_INSTRUCTIONS_THUMB2. > > Signed-off-by: Paul Enman <paul.enman@gmail.com> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > --- > package/uclibc/uclibc.mk | 19 +++++++++++++++++-- > 1 file changed, 17 insertions(+), 2 deletions(-) > > diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk > index 88a4a8c..ce706e0 100644 > --- a/package/uclibc/uclibc.mk > +++ b/package/uclibc/uclibc.mk > @@ -75,9 +75,23 @@ define UCLIBC_ARM_ABI_CONFIG > $(call KCONFIG_ENABLE_OPT,CONFIG_ARM_EABI,$(@D)/.config) > endef > > -# Thumb build is broken with threads, build in ARM mode > -ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB)$(BR2_TOOLCHAIN_HAS_THREADS),yy) > +# Thumb1 build is broken with threads with old gcc versions (4.7 and > +# 4.8). Since all cores supporting Thumb1 also support ARM, we use ARM > +# code in this case. > +ifeq ($(BR2_GCC_VERSION_4_7_X)$(BR2_GCC_VERSION_4_8_X):$(BR2_ARM_INSTRUCTIONS_THUMB)$(BR2_TOOLCHAIN_HAS_THREADS),y:yy) This would need to become something like ifeq ($(BR2_GCC_VERSION_4_7_X)$(BR2_GCC_VERSION_4_8_X):$(BR2_ARM_INSTRUCTIONS_THUMB):$(BR2_ARM_CPU_HAS_THUMB2):$(BR2_TOOLCHAIN_HAS_THREADS),y:y::y) But that is horrible, so some auxiliary variables should be introduced. Or actually, it could be ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB),y) ifeq ($(BR2_GCC_VERSION_4_7_X)$(BR2_GCC_VERSION_4_8_X):$(BR2_ARM_CPU_HAS_THUMB2):$(BR2_TOOLCHAIN_HAS_THREADS),y::y) ...arm... else ...thumb... endif else ...arm... endif Regards, Arnout > UCLIBC_EXTRA_CFLAGS += -marm > +define UCLIBC_ARM_THUMB_CONFIG > + $(call KCONFIG_DISABLE_OPT,COMPILE_IN_THUMB_MODE,$(@D)/.config) > +endef > +else ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB)$(BR2_ARM_INSTRUCTIONS_THUMB2),y) > +define UCLIBC_ARM_THUMB_CONFIG > + $(call KCONFIG_ENABLE_OPT,COMPILE_IN_THUMB_MODE,$(@D)/.config) > + $(call KCONFIG_DISABLE_OPT,UCLIBC_HAS_CONTEXT_FUNCS,$(@D)/.config) > +endef > +else > +define UCLIBC_ARM_THUMB_CONFIG > + $(call KCONFIG_DISABLE_OPT,COMPILE_IN_THUMB_MODE,$(@D)/.config) > +endef > endif > > ifeq ($(BR2_UCLIBC_ARM_BX),y) > @@ -362,6 +376,7 @@ define UCLIBC_KCONFIG_FIXUP_CMDS > $(UCLIBC_ARC_TYPE_CONFIG) > $(UCLIBC_ARC_PAGE_SIZE_CONFIG) > $(UCLIBC_ARM_ABI_CONFIG) > + $(UCLIBC_ARM_THUMB_CONFIG) > $(UCLIBC_ARM_BX_CONFIG) > $(UCLIBC_MIPS_ABI_CONFIG) > $(UCLIBC_MIPS_ISA_CONFIG) >
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > From: Paul Enman <paul.enman@gmail.com> > Until now, when thumb was selected with threads, we were forcing ARM > mode to be used, to workaround some problems building uClibc with > threads in Thumb mode. Also, we were never enabling Thumb mode in > uClibc when Thumb2 was selected in the configuration. > Therefore, this commit updates the uclibc.mk logic to: > - Force ARM mode only when gcc 4.7 or 4.8 is selected with Thumb1 and > threads. We also explicitly disable COMPILE_IN_THUMB_MODE when we > fall in this situation. With newer gcc versions, starting 4.9, this > problem is fixed and we can build uClibc in Thumb1 mode. > - Enable COMPILE_IN_THUMB_MODE when Thumb1 or Thumb2 is selected. We > need to disable context functions since they don't build in Thumb > mode. Why do we need to tell uClibc that we are building in thumb1/2 mode? From a quick grep this just adds -mthumb to CFLAGS, which shouldn't be needed as we've already configured the compiler to do so by default and enables USE_BX + USE_LDREXSTREX. Now, I don't know enough of the finer details about this. I thought BX was for thumb1 interworking with classical ARM code and not needed for thumb2, so isn't it just adding overhead for thumb2? I also see that enabling this option will break thumb compilation on arm920t. Luckily Yann is the author of this logic in uClibc, so lets ask him ;) > - Disable COMPILE_IN_THUMB_MODE explicitly otherwise. > This allows to build a Thumb2 toolchain on ARMv7-M for example. What wasn't working before?
Hello, On Thu, 17 Mar 2016 12:21:55 +0100, Peter Korsgaard wrote: > > - Force ARM mode only when gcc 4.7 or 4.8 is selected with Thumb1 and > > threads. We also explicitly disable COMPILE_IN_THUMB_MODE when we > > fall in this situation. With newer gcc versions, starting 4.9, this > > problem is fixed and we can build uClibc in Thumb1 mode. > > > - Enable COMPILE_IN_THUMB_MODE when Thumb1 or Thumb2 is selected. We > > need to disable context functions since they don't build in Thumb > > mode. > > Why do we need to tell uClibc that we are building in thumb1/2 mode? > From a quick grep this just adds -mthumb to CFLAGS, which shouldn't be > needed as we've already configured the compiler to do so by default and > enables USE_BX + USE_LDREXSTREX. > > Now, I don't know enough of the finer details about this. I thought BX > was for thumb1 interworking with classical ARM code and not needed for > thumb2, so isn't it just adding overhead for thumb2? I also see that > enabling this option will break thumb compilation on arm920t. Interworking allows on pre-ARMv5 code to fix ARM and Thumb code. With ARMv5, it is not needed if I remember correctly, thanks to the bx/blx instructions. > Luckily Yann is the author of this logic in uClibc, so lets ask him ;) > > > - Disable COMPILE_IN_THUMB_MODE explicitly otherwise. > > > This allows to build a Thumb2 toolchain on ARMv7-M for example. > > What wasn't working before? Not sure. In fact this patch was kind-of the starting point of my series, I wanted to get rid of it from patchwork :) I'll have a closer look. Thomas
Hello, On Thu, 17 Mar 2016 12:21:55 +0100, Peter Korsgaard wrote: > > - Force ARM mode only when gcc 4.7 or 4.8 is selected with Thumb1 and > > threads. We also explicitly disable COMPILE_IN_THUMB_MODE when we > > fall in this situation. With newer gcc versions, starting 4.9, this > > problem is fixed and we can build uClibc in Thumb1 mode. > > > - Enable COMPILE_IN_THUMB_MODE when Thumb1 or Thumb2 is selected. We > > need to disable context functions since they don't build in Thumb > > mode. > > Why do we need to tell uClibc that we are building in thumb1/2 mode? > From a quick grep this just adds -mthumb to CFLAGS, which shouldn't be > needed as we've already configured the compiler to do so by default and > enables USE_BX + USE_LDREXSTREX. USE_LDREXSTREX is mandatory for uClibc to build on Thumb2 (see commit https://lists.uclibc.org/pipermail/uclibc/2014-November/048704.html). Otherwise, the build fails with: /tmp/ccsjUC4D.s: Assembler messages: /tmp/ccsjUC4D.s:31: Error: selected processor does not support ARM opcodes /tmp/ccsjUC4D.s:32: Error: attempt to use an ARM instruction on a Thumb-only processor -- `swp r2,r2,[r0]' /tmp/ccsjUC4D.s:33: Error: attempt to use an ARM instruction on a Thumb-only processor -- `orr r3,pc,#1' /tmp/ccsjUC4D.s:34: Error: attempt to use an ARM instruction on a Thumb-only processor -- `bx r3' make[2]: *** [libpthread/linuxthreads.old/pt-machine.o] Error 1 > Now, I don't know enough of the finer details about this. I thought BX > was for thumb1 interworking with classical ARM code and not needed for > thumb2, so isn't it just adding overhead for thumb2? I also see that > enabling this option will break thumb compilation on arm920t. What makes you think it will fail to build ? I believe you think: #if defined(__USE_BX__) # if (__ARM_ARCH <= 4 && !defined __ARM_ARCH_4T__) # error Use of BX was requested, but is not available on the target processor. # endif /* ARCH level */ #endif /* __USE_BX__ */ will make it fail to build. But ARM920T is an ARMv4T, not an ARMv4. Quoting from http://www.atmel.com/Images/ARM_920T_TRM.pdf: """ The ARM920T processor incorporates the ARM9TDMI integer core, which implements the ARM architecture v4T. """ However, it could indeed break StrongARM and FA256, which implement the ARMv4 instruction set. *But* for those two cores, we don't select BR2_ARM_CPU_HAS_THUMB, so you can't switch them to Thumb mode. But isn't this all moot since Thumb appeared with ARMv4T ? > Luckily Yann is the author of this logic in uClibc, so lets ask him ;) > > > - Disable COMPILE_IN_THUMB_MODE explicitly otherwise. > > > This allows to build a Thumb2 toolchain on ARMv7-M for example. > > What wasn't working before? See above. If you don't enable COMPILE_IN_THUMB_MODE, you can't enable USE_LDREXSTREX. So I think we should: 1/ Enable COMPILE_IN_THUMB_MODE whenever ARM_INSTRUCTIONS_THUMB(2) is enabled. 2/ Enable USE_BX whenever ARM_INSTRUCTIONS_THUMB(2) is enabled. I don't see why USE_BX for later cores can cause performance problems, it's just about using a simple bx instruction to switch between ARM and Thumb modes. 3/ Enable USE_LDREXSTREX whenver ARM_INSTRUCTIONS_THUMB(2) is enabled *and* we're on ARMv7. Otherwise, disable it. Thoughts ? Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > Hello, > On Thu, 17 Mar 2016 12:21:55 +0100, Peter Korsgaard wrote: >> > - Force ARM mode only when gcc 4.7 or 4.8 is selected with Thumb1 and >> > threads. We also explicitly disable COMPILE_IN_THUMB_MODE when we >> > fall in this situation. With newer gcc versions, starting 4.9, this >> > problem is fixed and we can build uClibc in Thumb1 mode. >> >> > - Enable COMPILE_IN_THUMB_MODE when Thumb1 or Thumb2 is selected. We >> > need to disable context functions since they don't build in Thumb >> > mode. >> >> Why do we need to tell uClibc that we are building in thumb1/2 mode? >> From a quick grep this just adds -mthumb to CFLAGS, which shouldn't be >> needed as we've already configured the compiler to do so by default and >> enables USE_BX + USE_LDREXSTREX. > USE_LDREXSTREX is mandatory for uClibc to build on Thumb2 (see commit > https://lists.uclibc.org/pipermail/uclibc/2014-November/048704.html). > Otherwise, the build fails with: Ahh, ok - Good to know. So this is only really needed for thumb2-only CPUs (cortex-M). Completely unrelated, but notice that my browser wouldn't let me visit https://lists.uclibc.org because of the HSTS header on uclibc.org and the lists.uclibc.org vhost using a certificate for *.osuosl.org. It does work for lists.buildroot.org as we don't do HSTS for subdomains. > What makes you think it will fail to build ? > I believe you think: > #if defined(__USE_BX__) > # if (__ARM_ARCH <= 4 && !defined __ARM_ARCH_4T__) > # error Use of BX was requested, but is not available on the target processor. > # endif /* ARCH level */ > #endif /* __USE_BX__ */ > will make it fail to build. > But ARM920T is an ARMv4T, not an ARMv4. Quoting from > http://www.atmel.com/Images/ARM_920T_TRM.pdf: Ahh yes, true. > So I think we should: > 1/ Enable COMPILE_IN_THUMB_MODE whenever ARM_INSTRUCTIONS_THUMB(2) is > enabled. Ok. > 2/ Enable USE_BX whenever ARM_INSTRUCTIONS_THUMB(2) is enabled. I > don't see why USE_BX for later cores can cause performance problems, > it's just about using a simple bx instruction to switch between ARM > and Thumb modes. > 3/ Enable USE_LDREXSTREX whenver ARM_INSTRUCTIONS_THUMB(2) is enabled > *and* we're on ARMv7. Otherwise, disable it. With ARMv7 I guess you mean thumb2-only CPUs (cortex-m)? But COMPILE_IN_THUMB_MODE selects USE_BX / USE_LDREXTREX, so we cannot really do that. I guess we should leave COMPILE_IN_THUMB_MODE alone (it just passes -mthumb in CFLAGS which we don't need), and just enable USE_BX/LDREXTREX when needed.
Hello, On Thu, 17 Mar 2016 22:44:16 +0100, Peter Korsgaard wrote: > > USE_LDREXSTREX is mandatory for uClibc to build on Thumb2 (see commit > > https://lists.uclibc.org/pipermail/uclibc/2014-November/048704.html). > > Otherwise, the build fails with: > > Ahh, ok - Good to know. So this is only really needed for thumb2-only > CPUs (cortex-M). Mandatory for Thumb2-only CPUs, but perfectly usable for ARMv7-A as well. > Completely unrelated, but notice that my browser wouldn't let > me visit https://lists.uclibc.org because of the HSTS header on > uclibc.org and the lists.uclibc.org vhost using a certificate for > *.osuosl.org. Same here, I have to use Firefox to be able to bypass the "security checks". Chromium doesn't allow to bypass such security checks (at least by default). > > So I think we should: > > > 1/ Enable COMPILE_IN_THUMB_MODE whenever ARM_INSTRUCTIONS_THUMB(2) is > > enabled. > > Ok. > > > 2/ Enable USE_BX whenever ARM_INSTRUCTIONS_THUMB(2) is enabled. I > > don't see why USE_BX for later cores can cause performance problems, > > it's just about using a simple bx instruction to switch between ARM > > and Thumb modes. > > > 3/ Enable USE_LDREXSTREX whenver ARM_INSTRUCTIONS_THUMB(2) is enabled > > *and* we're on ARMv7. Otherwise, disable it. > > With ARMv7 I guess you mean thumb2-only CPUs (cortex-m)? > > But COMPILE_IN_THUMB_MODE selects USE_BX / USE_LDREXTREX, so we cannot > really do that. > > I guess we should leave COMPILE_IN_THUMB_MODE alone (it just passes > -mthumb in CFLAGS which we don't need), and just enable USE_BX/LDREXTREX > when needed. USE_LDREXSTREX depends on COMPILE_IN_THUMB_MODE, so you can't have USE_LDREXSTREX without having COMPILE_IN_THUMB_MODE. So, instead what I've done is cook a set of patches for uClibc that simply remove USE_BX, USE_LDREXSTREX and COMPILE_IN_THUMB. None of those options are needed, everything can be guessed by looking at the selected ARM variant, and for COMPILE_IN_THUMB, by passing -mthumb. See https://github.com/tpetazzoni/uclibc-ng/commits/arm-simplifications. Build testing in progress. I'm testing: * Cortex-M4, so a Thumb2-only core * Cortex-A in Thumb2 mode * ARM920T in Thumb mode * FA526, which is an ARMv4 (and therefore doesn't support Thumb) Any other config you think is relevant? Thanks, Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: Hi, >> Ahh, ok - Good to know. So this is only really needed for thumb2-only >> CPUs (cortex-M). > Mandatory for Thumb2-only CPUs, but perfectly usable for ARMv7-A as > well. True. >> Completely unrelated, but notice that my browser wouldn't let >> me visit https://lists.uclibc.org because of the HSTS header on >> uclibc.org and the lists.uclibc.org vhost using a certificate for >> *.osuosl.org. > Same here, I have to use Firefox to be able to bypass the "security > checks". Chromium doesn't allow to bypass such security checks (at > least by default). Yes, quite a mess :/ >> With ARMv7 I guess you mean thumb2-only CPUs (cortex-m)? >> >> But COMPILE_IN_THUMB_MODE selects USE_BX / USE_LDREXTREX, so we cannot >> really do that. >> >> I guess we should leave COMPILE_IN_THUMB_MODE alone (it just passes >> -mthumb in CFLAGS which we don't need), and just enable USE_BX/LDREXTREX >> when needed. > USE_LDREXSTREX depends on COMPILE_IN_THUMB_MODE, so you can't have > USE_LDREXSTREX without having COMPILE_IN_THUMB_MODE. Ahh yes, but USE_BX is independent at least, so COMPILE_IN_THUMB_MODE (which implies USE_LDREXSTREX) for thumb2, and NOT for classic ARM/thumb1 mode. > So, instead what I've done is cook a set of patches for uClibc that > simply remove USE_BX, USE_LDREXSTREX and COMPILE_IN_THUMB. None of > those options are needed, everything can be guessed by looking at the > selected ARM variant, and for COMPILE_IN_THUMB, by passing -mthumb. > See > https://github.com/tpetazzoni/uclibc-ng/commits/arm-simplifications. Thanks, it imho looks sensible. > Build testing in progress. I'm testing: > * Cortex-M4, so a Thumb2-only core > * Cortex-A in Thumb2 mode > * ARM920T in Thumb mode > * FA526, which is an ARMv4 (and therefore doesn't support Thumb) > Any other config you think is relevant? No, I think this pretty much covers it. There's afaik an arm11 variant supporting thumb2, but I've never seen any SoCs using it and we don't support it Buildroot.
diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk index 88a4a8c..ce706e0 100644 --- a/package/uclibc/uclibc.mk +++ b/package/uclibc/uclibc.mk @@ -75,9 +75,23 @@ define UCLIBC_ARM_ABI_CONFIG $(call KCONFIG_ENABLE_OPT,CONFIG_ARM_EABI,$(@D)/.config) endef -# Thumb build is broken with threads, build in ARM mode -ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB)$(BR2_TOOLCHAIN_HAS_THREADS),yy) +# Thumb1 build is broken with threads with old gcc versions (4.7 and +# 4.8). Since all cores supporting Thumb1 also support ARM, we use ARM +# code in this case. +ifeq ($(BR2_GCC_VERSION_4_7_X)$(BR2_GCC_VERSION_4_8_X):$(BR2_ARM_INSTRUCTIONS_THUMB)$(BR2_TOOLCHAIN_HAS_THREADS),y:yy) UCLIBC_EXTRA_CFLAGS += -marm +define UCLIBC_ARM_THUMB_CONFIG + $(call KCONFIG_DISABLE_OPT,COMPILE_IN_THUMB_MODE,$(@D)/.config) +endef +else ifeq ($(BR2_ARM_INSTRUCTIONS_THUMB)$(BR2_ARM_INSTRUCTIONS_THUMB2),y) +define UCLIBC_ARM_THUMB_CONFIG + $(call KCONFIG_ENABLE_OPT,COMPILE_IN_THUMB_MODE,$(@D)/.config) + $(call KCONFIG_DISABLE_OPT,UCLIBC_HAS_CONTEXT_FUNCS,$(@D)/.config) +endef +else +define UCLIBC_ARM_THUMB_CONFIG + $(call KCONFIG_DISABLE_OPT,COMPILE_IN_THUMB_MODE,$(@D)/.config) +endef endif ifeq ($(BR2_UCLIBC_ARM_BX),y) @@ -362,6 +376,7 @@ define UCLIBC_KCONFIG_FIXUP_CMDS $(UCLIBC_ARC_TYPE_CONFIG) $(UCLIBC_ARC_PAGE_SIZE_CONFIG) $(UCLIBC_ARM_ABI_CONFIG) + $(UCLIBC_ARM_THUMB_CONFIG) $(UCLIBC_ARM_BX_CONFIG) $(UCLIBC_MIPS_ABI_CONFIG) $(UCLIBC_MIPS_ISA_CONFIG)