[PATCH] [ARC] Fix generation of specs
With no trailing space in LINK_EH_SPEC linker spec gets generated as:
>8-
%{!r:--build-id} --eh-frame-hdr%{h*} ...
>8-
or even worse if hash style is added:
>8-
%{!r:--build-id} --eh-frame-hdr--hash-style=sysv %{h*} ...
>8-
Now if that spec is really used by LD then it fails inevitably
saying that it doesn't know option "--eh-frame-hdr--hash-style=sysv".
Cc: Andrew Burgess
Cc: Claudiu Zissulescu
---
gcc/config/arc/linux.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/arc/linux.h b/gcc/config/arc/linux.h
index 96d548eae341..62ebe4de0fc7 100644
--- a/gcc/config/arc/linux.h
+++ b/gcc/config/arc/linux.h
@@ -98,7 +98,7 @@ along with GCC; see the file COPYING3. If not see
Signalize that because we have fde-glibc, we don't need all C shared libs
linked against -lgcc_s. */
#undef LINK_EH_SPEC
-#define LINK_EH_SPEC "--eh-frame-hdr"
+#define LINK_EH_SPEC "--eh-frame-hdr "
#endif
#undef SUBTARGET_CPP_SPEC
--
2.17.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] [ARC] Fix generation of specs
The patch is missing the entry change log. Otherwise is ok. I'll push it with
the mentioned changes.
Thank you,
Claudiu
> -Original Message-
> From: Alexey Brodkin [mailto:abrod...@synopsys.com]
> Sent: Thursday, September 13, 2018 9:41 AM
> To: gcc-patc...@gcc.gnu.org
> Cc: linux-snps-arc@lists.infradead.org; Alexey Brodkin
> ; Andrew Burgess
> ; Claudiu Zissulescu
>
> Subject: [PATCH] [ARC] Fix generation of specs
>
> With no trailing space in LINK_EH_SPEC linker spec gets generated as:
> >8-
> %{!r:--build-id} --eh-frame-hdr%{h*} ...
> >8-
>
> or even worse if hash style is added:
> >8-
> %{!r:--build-id} --eh-frame-hdr--hash-style=sysv %{h*} ...
> >8-
>
> Now if that spec is really used by LD then it fails inevitably
> saying that it doesn't know option "--eh-frame-hdr--hash-style=sysv".
>
> Cc: Andrew Burgess
> Cc: Claudiu Zissulescu
> ---
> gcc/config/arc/linux.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/arc/linux.h b/gcc/config/arc/linux.h
> index 96d548eae341..62ebe4de0fc7 100644
> --- a/gcc/config/arc/linux.h
> +++ b/gcc/config/arc/linux.h
> @@ -98,7 +98,7 @@ along with GCC; see the file COPYING3. If not see
> Signalize that because we have fde-glibc, we don't need all C shared libs
> linked against -lgcc_s. */
> #undef LINK_EH_SPEC
> -#define LINK_EH_SPEC "--eh-frame-hdr"
> +#define LINK_EH_SPEC "--eh-frame-hdr "
> #endif
>
> #undef SUBTARGET_CPP_SPEC
> --
> 2.17.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] [ARC] Fix generation of specs
Hi Claus, On Thu, 2018-09-13 at 09:59 +0200, Claudiu Zissulescu wrote: > The patch is missing the entry change log. Otherwise is ok. I'll push it with > the mentioned changes. Thanks for taking care. Also may we have it back-ported to 8.x branch so it will be a part of 8.3 release later? -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules
Hi Yamada-san,
On Wed, Sep 12, 2018 at 3:02 AM Masahiro Yamada
wrote:
> 2018-09-12 0:40 GMT+09:00 Rob Herring :
> > On Mon, Sep 10, 2018 at 10:04 AM Rob Herring wrote:
> >> There is nothing arch specific about building dtb files other than their
> >> location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
> >> The dependencies and supported targets are all slightly different.
> >> Also, a cross-compiler for each arch is needed, but really the host
> >> compiler preprocessor is perfectly fine for building dtbs. Move the
> >> build rules to a common location and remove the arch specific ones. This
> >> is done in a single step to avoid warnings about overriding rules.
> >>
> >> The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
> >> These pull in several dependencies some of which need a target compiler
> >> (specifically devicetable-offsets.h) and aren't needed to build dtbs.
> >> All that is really needed is dtc, so adjust the dependencies to only be
> >> dtc.
> >>
> >> This change enables support 'dtbs_install' on some arches which were
> >> missing the target.
> >
> > [...]
> >
> >> @@ -1215,6 +1215,33 @@ kselftest-merge:
> >> $(srctree)/tools/testing/selftests/*/config
> >> +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig
> >>
> >> +#
> >> ---
> >> +# Devicetree files
> >> +
> >> +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),)
> >> +dtstree := arch/$(SRCARCH)/boot/dts
> >> +endif
> >> +
> >> +ifdef CONFIG_OF_EARLY_FLATTREE
> >
> > This can be true when dtstree is unset. So this line should be this
> > instead to fix the 0-day reported error:
> >
> > ifneq ($(dtstree),)
> >
> >> +
> >> +%.dtb : scripts_dtc
> >> + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
> >> +
> >> +PHONY += dtbs dtbs_install
> >> +dtbs: scripts_dtc
> >> + $(Q)$(MAKE) $(build)=$(dtstree)
> >> +
> >> +dtbs_install: dtbs
> >> + $(Q)$(MAKE) $(dtbinst)=$(dtstree)
> >> +
> >> +all: dtbs
> >> +
> >> +endif
>
>
> Ah, right.
> Even x86 can enable OF and OF_UNITTEST.
>
>
>
> Another solution might be,
> guard it by 'depends on ARCH_SUPPORTS_OF'.
>
>
>
> This is actually what ACPI does.
>
> menuconfig ACPI
> bool "ACPI (Advanced Configuration and Power Interface) Support"
> depends on ARCH_SUPPORTS_ACPI
> ...
ACPI is a real platform feature, as it depends on firmware.
CONFIG_OF can be enabled, and DT overlays can be loaded, on any platform,
even if it has ACPI ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: Get rid of toolchain check
This check is very naive: we simply test if GCC invoked without "-mcpu=XXX" has ARC700 define set. In that case we think that GCC was built with "--with-cpu=arc700" and has libgcc built for ARC700. Otherwise if ARC700 is not defined we think that everythng was built for ARCv2. But in reality our life is much more interesting. 1. Regardless of GCC configuration (i.e. what we pass in "--with-cpu" it may generate code for any ARC core). 2. libgcc might be built with explicitly specified "--mcpu=YYY" That's exactly what happens in case of multilibbed toolchains: - GCC is configured with default settings - All the libs built for many different CPU flavors I.e. that check gets in the way of usage of multilibbed toolchains. And even non-multilibbed toolchains are affected. OpenEmbedded also builds GCC without "--with-cpu" because each and every target component later is compiled with explicitly set "-mcpu=ZZZ". Signed-off-by: Alexey Brodkin --- arch/arc/Makefile | 14 -- 1 file changed, 14 deletions(-) diff --git a/arch/arc/Makefile b/arch/arc/Makefile index 6c1b20dd76ad..16ae8675116e 100644 --- a/arch/arc/Makefile +++ b/arch/arc/Makefile @@ -20,20 +20,6 @@ cflags-y += -fno-common -pipe -fno-builtin -mmedium-calls -D__linux__ cflags-$(CONFIG_ISA_ARCOMPACT) += -mA7 cflags-$(CONFIG_ISA_ARCV2) += -mcpu=archs -is_700 = $(shell $(CC) -dM -E - < /dev/null | grep -q "ARC700" && echo 1 || echo 0) - -ifdef CONFIG_ISA_ARCOMPACT -ifeq ($(is_700), 0) -$(error Toolchain not configured for ARCompact builds) -endif -endif - -ifdef CONFIG_ISA_ARCV2 -ifeq ($(is_700), 1) -$(error Toolchain not configured for ARCv2 builds) -endif -endif - ifdef CONFIG_ARC_CURR_IN_REG # For a global register defintion, make sure it gets passed to every file # We had a customer reported bug where some code built in kernel was NOT using -- 2.17.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: Get rid of toolchain check
On Thu, Sep 13, 2018 at 3:24 PM Alexey Brodkin wrote: > > This check is very naive: we simply test if GCC invoked without > "-mcpu=XXX" has ARC700 define set. In that case we think that GCC > was built with "--with-cpu=arc700" and has libgcc built for ARC700. > > Otherwise if ARC700 is not defined we think that everythng was built > for ARCv2. > > But in reality our life is much more interesting. > > 1. Regardless of GCC configuration (i.e. what we pass in "--with-cpu" >it may generate code for any ARC core). > > 2. libgcc might be built with explicitly specified "--mcpu=YYY" > > That's exactly what happens in case of multilibbed toolchains: > - GCC is configured with default settings > - All the libs built for many different CPU flavors > > I.e. that check gets in the way of usage of multilibbed > toolchains. And even non-multilibbed toolchains are affected. > OpenEmbedded also builds GCC without "--with-cpu" because > each and every target component later is compiled with explicitly > set "-mcpu=ZZZ". > > Signed-off-by: Alexey Brodkin > --- > arch/arc/Makefile | 14 -- > 1 file changed, 14 deletions(-) +1 for this. Removing it also helps with my work to be able to build all the .dts files with only a host compiler. That also needs the hunk setting CROSS_COMPILE removed and not having a built-in dtb by default, but this is a step in the right direction. Acked-by: Rob Herring Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
