Re: [PATCH] kbuild: use more portable 'command -v' for cc-cross-prefix

[Masahiro Yamada]

On Mon, Jun 3, 2019 at 9:43 PM David Laight  wrote:
>
> From: Masahiro Yamada
> > Sent: 03 June 2019 12:45
> > On Mon, Jun 3, 2019 at 8:16 PM David Laight  wrote:
> > >
> > > From: Masahiro Yamada
> > > > Sent: 03 June 2019 11:49
> > > >
> > > > To print the pathname that will be used by shell in the current
> > > > environment, 'command -v' is a standardized way. [1]
> > > >
> > > > 'which' is also often used in scripting, but it is not portable.
> > >
> > > All uses of 'which' should be expunged.
> > > It is a bourne shell script that is trying to emulate a csh builtin.
> > > It is doomed to fail in corner cases.
> > > ISTR it has serious problems with shell functions and aliases.
> >
> > OK, I do not have time to check it treewide.
> > I expect somebody will contribute to it.
> >
> >
> >
> > BTW, I see yet another way to get the command path.
> >
> > 'type -path' is bash-specific.
>
> 'type' itself should be supported by all shells, but the output
> format (esp for errors) probably varies.
>
> > Maybe, we should do this too:
> >
> > diff --git a/scripts/mkuboot.sh b/scripts/mkuboot.sh
> > index 4b1fe09e9042..77829ee4268e 100755
> > --- a/scripts/mkuboot.sh
> > +++ b/scripts/mkuboot.sh
> > @@ -1,14 +1,14 @@
> > -#!/bin/bash
> > +#!/bin/sh
>
> /bin/sh might be 'dash' - which is just plain broken in so many ways.
> Try (IIRC) ${foo%${foo#bar}}
> It might even be the original SYSV /bin/sh which doesn't support $((expr))
> or ${foo#bar} - but that may break too much, but $SHELL might fix it.


We cannot use any tool
if you start to argue like
"Hey, I know ancient implementation that did not work as expected".

Nobody can cover all corner-cases.
That's why we have standard.

I think the reliable source is the
Open Group Specification.

The behavior of /bin/sh is defined here:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_01

${parameter%[word]} and ${parameter#[word]} are defined,
so we can use them in /bin/sh scripts.


> dash probably has the rather obscure bug in stripping '\n' from $(...)
> output that I found and fixed in NetBSD's ash may years ago.
> Try: foo="$(jot -b "" 130)"
> All 130 '\n' should be deleted.
> Mostly it fails to delete all the '\n', but it can remove extra ones!
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 
> 1PT, UK
> Registration No: 1397386 (Wales)



-- 
Best Regards
Masahiro Yamada

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] kbuild: use more portable 'command -v' for cc-cross-prefix

[Masahiro Yamada]

On Mon, Jun 3, 2019 at 10:09 PM David Laight  wrote:
>
> From: Masahiro Yamada
> > Sent: 03 June 2019 12:38
> > Hi David,
> >
> > On Mon, Jun 3, 2019 at 8:14 PM David Laight  wrote:
> > >
> > > From: Masahiro Yamada
> > > > Sent: 03 June 2019 11:49
> > > >
> > > > To print the pathname that will be used by shell in the current
> > > > environment, 'command -v' is a standardized way. [1]
> > > >
> > > > 'which' is also often used in scripting, but it is not portable.
> > > >
> > > > When I worked on commit bd55f96fa9fc ("kbuild: refactor cc-cross-prefix
> > > > implementation"), I was eager to use 'command -v' but it did not work.
> > > > (The reason is explained below.)
> > > >
> > > > I kept 'which' as before but got rid of '> /dev/null 2>&1' as I
> > > > thought it was no longer needed. Sorry, I was wrong.
> > > >
> > > > It works well on my Ubuntu machine, but Alexey Brodkin reports annoying
> > > > warnings from the 'which' on CentOS 7 when the given command is not
> > > > found in the PATH environment.
> > > >
> > > >   $ which foo
> > > >   which: no foo in 
> > > > (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
> > > >
> > > > Given that behavior of 'which' is different on environment, I want
> > > > to try 'command -v' again.
> > > >
> > > > The specification [1] clearly describes the behavior of 'command -v'
> > > > when the given command is not found:
> > > >
> > > >   Otherwise, no output shall be written and the exit status shall 
> > > > reflect
> > > >   that the name was not found.
> > > >
> > > > However, we need a little magic to use 'command -v' from Make.
> > > >
> > > > $(shell ...) passes the argument to a subshell for execution, and
> > > > returns the standard output of the command.
> > > >
> > > > Here is a trick. GNU Make may optimize this by executing the command
> > > > directly instead of forking a subshell, if no shell special characters
> > > > are found in the command line and omitting the subshell will not
> > > > change the behavior.
> > > >
> > > > In this case, no shell special character is used. So, Make will try
> > > > to run the command directly. However, 'command' is a shell-builtin
> > > > command. In fact, Make has a table of shell-builtin commands because
> > > > it must spawn a subshell to execute them.
> > > >
> > > > Until recently, 'command' was missing in the table.
> > > >
> > > > This issue was fixed by the following commit:
> > > >
> > > > | commit 1af314465e5dfe3e8baa839a32a72e83c04f26ef
> > > > | Author: Paul Smith 
> > > > | Date:   Sun Nov 12 18:10:28 2017 -0500
> > > > |
> > > > | * job.c: Add "command" as a known shell built-in.
> > > > |
> > > > | This is not a POSIX shell built-in but it's common in UNIX shells.
> > > > | Reported by Nick Bowler .
> > > >
> > > > This is not included in any released versions of Make yet.
> > > > (But, some distributions may have back-ported the fix-up.)
> > > >
> > > > To trick Make and let it fork the subshell, I added a shell special
> > > > character '~'. We may be able to get rid of this workaround someday,
> > > > but it is very far into the future.
> > > >
> > > > [1] 
> > > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html
> > > >
> > > > Fixes: bd55f96fa9fc ("kbuild: refactor cc-cross-prefix implementation")
> > > > Cc: linux-stable  # 5.1
> > > > Reported-by: Alexey Brodkin 
> > > > Signed-off-by: Masahiro Yamada 
> > > > ---
> > > >
> > > >  scripts/Kbuild.include | 5 -
> > > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
> > > > index 85d758233483..5a32ca80c3f6 100644
> > > > --- a/scripts/Kbuild.include
> > > > +++ b/scripts/Kbuild.include
> > > > @@ -74,8 +74,11 @@ endef
> > > >  # Usage: CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu- 
> > > > m68k-linux-)
> > > >  # Return first  where a gcc is found in PATH.
> > > >  # If no gcc found in PATH with listed prefixes return nothing
> > > > +#
> > > > +# Note: the special character '~' forces Make to invoke a shell. This 
> > > > workaround
> > > > +# is needed because this issue was only fixed after GNU Make 4.2.1 
> > > > release.
> > > >  cc-cross-prefix = $(firstword $(foreach c, $(filter-out -%, $(1)), \
> > > > - $(if $(shell which $(c)gcc), 
> > > > $(c
> > > > + $(if $(shell command -v $(c)gcc ~), 
> > > > $(c
> > >
> > > I see a problem here:
> > > command -v foo bar
> > > could be deemed to be an error (extra argument).
> >
> > OK, the specification does not allow to pass arguments
> > with -v.
> >
> >
> > > You could use:
> > > $(shell sh -c "command -v $(c)gcc")
> > > or maybe:
> > > $(shell command$${x:+} -v $(c)gcc)
> >
> >
> > How about this?
> >
> >   $(shell : ~; command -v $(c)gcc)
>
> Overcomplicated 
>
> I've not looked at the list of 'special characters' in make,
> but I suspect any 

Re: [PATCH] ARC: build: Try to guess CROSS_COMPILE with cc-cross-prefix

[Masahiro Yamada]

On Tue, Jun 4, 2019 at 1:27 AM Vineet Gupta  wrote:
>
> On 6/2/19 11:31 PM, Alexey Brodkin wrote:
> > For a long time we used to hard-code CROSS_COMPILE prefix
> > for ARC until it started to cause problems, so we decided to
> > solely rely on CROSS_COMPILE externally set by a user:
> > commit 40660f1fcee8 ("ARC: build: Don't set CROSS_COMPILE in arch's 
> > Makefile").
> >
> > While it works perfectly fine for build-systems where the prefix
> > gets defined anyways for us human beings it's quite an annoying
> > requirement especially given most of time the same one prefix
> > "arc-linux-" is all what we need.
> >
> > It looks like finally we're getting the best of both worlds:
> >  1. W/o cross-toolchain we still may install headers, build .dtb etc
> >  2. W/ cross-toolchain get the kerne built with only ARCH=arc
> >
> > Inspired by [1] & [2].
> >
> > [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-May/005788.html
> > [2] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc2b47b55f17
> >
> > A side note: even though "cc-cross-prefix" does its job it pollutes
> > console with output of "which" for all the prefixes it didn't manage to find
> > a matching cross-compiler for like that:
> > | # ARCH=arc make defconfig
> > | which: no arceb-linux-gcc in (~/.local/bin:~/bin:/usr/bin:/usr/sbin)
> > | *** Default configuration is based on 'nsim_hs_defconfig'
> >
> > Signed-off-by: Alexey Brodkin 
> > Cc: Masahiro Yamada 
> > Cc: Vineet Gupta 
>
> Not a big deal but I'd propose we add "Suggested-by: vgupta" since that is 
> where
> it came from.
>
> @Masahiro san I suppose you are OK with this, so perhaps an Ack etc would be 
> nice
> to have.

FWIW,
Reviewed-by: Masahiro Yamada 



-- 
Best Regards
Masahiro Yamada

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [GIT PULL] ARC updates for 5.2-rc4

[pr-tracker-bot]

The pull request you sent on Mon, 3 Jun 2019 14:04:16 -0700:

> git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/ tags/arc-5.2-rc4

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/788a024921c48985939f8241c1ff862a7374d8f9

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: single copy atomicity for double load/stores on 32-bit systems

[Vineet Gupta]

On 6/3/19 1:13 PM, Paul E. McKenney wrote:
> On Mon, Jun 03, 2019 at 06:08:35PM +, Vineet Gupta wrote:
>> On 5/31/19 1:21 AM, Peter Zijlstra wrote:
 I'm not sure how to interpret "natural alignment" for the case of double
 load/stores on 32-bit systems where the hardware and ABI allow for 4 byte
 alignment (ARCv2 LDD/STD, ARM LDRD/STRD )
>>> Natural alignment: !((uintptr_t)ptr % sizeof(*ptr))
>>>
>>> For any u64 type, that would give 8 byte alignment. the problem
>>> otherwise being that your data spans two lines/pages etc..
>> Sure, but as Paul said, if the software doesn't expect them to be atomic by
>> default, they could span 2 hardware lines to keep the implementation 
>> simpler/sane.
> I could imagine 8-byte types being only four-byte aligned on 32-bit systems,
> but it would be quite a surprise on 64-bit systems.

Totally agree !

Thx,
-Vineet

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[GIT PULL] ARC updates for 5.2-rc4

[Vineet Gupta]

Hi Linus,

Please pull.

Thx,
-Vineet
->
The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:

  Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/ tags/arc-5.2-rc4

for you to fetch changes up to 46e04c25e72f002d0d14be072300c2dd827d99b6:

  ARC: [plat-hsdk] Get rid of inappropriate PHY settings (2019-05-28 10:09:31 
-0700)


ARC fixes for 5.2-rc4

 - Fix for userspace trying to access kernel vaddr space

 - HSDK platform DT updates

 - Cleanup some build warnings


Alexey Brodkin (1):
  ARC: [plat-hsdk] Get rid of inappropriate PHY settings

Eugeniy Paltsev (3):
  ARC: mm: SIGSEGV userspace trying to access kernel virtual memory
  ARC: [plat-hsdk]: enable creg-gpio controller
  ARC: [plat-hsdk]: Add support of Vivante GPU

Jose Abreu (2):
  ARC: [plat-hsdk]: Add missing multicast filter bins number to GMAC node
  ARC: [plat-hsdk]: Add missing FIFO size entry in GMAC node

Vineet Gupta (1):
  ARC: fix build warnings

 arch/arc/boot/dts/hsdk.dts  | 45 +
 arch/arc/configs/hsdk_defconfig |  3 ++-
 arch/arc/include/asm/cmpxchg.h  | 14 +
 arch/arc/mm/fault.c |  9 +++--
 arch/arc/mm/tlb.c   | 13 +++-
 5 files changed, 64 insertions(+), 20 deletions(-)

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: single copy atomicity for double load/stores on 32-bit systems

[Paul E. McKenney]

On Mon, Jun 03, 2019 at 06:08:35PM +, Vineet Gupta wrote:
> On 5/31/19 1:21 AM, Peter Zijlstra wrote:
> >> I'm not sure how to interpret "natural alignment" for the case of double
> >> load/stores on 32-bit systems where the hardware and ABI allow for 4 byte
> >> alignment (ARCv2 LDD/STD, ARM LDRD/STRD )
> > Natural alignment: !((uintptr_t)ptr % sizeof(*ptr))
> >
> > For any u64 type, that would give 8 byte alignment. the problem
> > otherwise being that your data spans two lines/pages etc..
> 
> Sure, but as Paul said, if the software doesn't expect them to be atomic by
> default, they could span 2 hardware lines to keep the implementation 
> simpler/sane.

I could imagine 8-byte types being only four-byte aligned on 32-bit systems,
but it would be quite a surprise on 64-bit systems.

Thanx, Paul


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: single copy atomicity for double load/stores on 32-bit systems

[Vineet Gupta]

On 5/31/19 2:41 AM, David Laight wrote:
>> While it seems reasonable form hardware pov to not implement such atomicity 
>> by
>> default it seems there's an additional burden on application writers. They 
>> could
>> be happily using a lockless algorithm with just a shared flag between 2 
>> threads
>> w/o need for any explicit synchronization. But upgrade to a new compiler 
>> which
>> aggressively "packs" struct rendering long long 32-bit aligned (vs. 64-bit 
>> before)
>> causing the code to suddenly stop working. Is the onus on them to declare 
>> such
>> memory as c11 atomic or some such.
> A 'new' compiler can't suddenly change the alignment rules for structure 
> elements.
> The alignment rules will be part of the ABI.
> 
> More likely is that the structure itself is unexpectedly allocated on
> an 8n+4 boundary due to code changes elsewhere.

Indeed thats what I meant that the layout changed as is typical of a new 
compiler.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: single copy atomicity for double load/stores on 32-bit systems

[Vineet Gupta]

On 5/31/19 1:21 AM, Peter Zijlstra wrote:
> And I'll stand by my earlier conviction that any architecture that has a
> native u64 (be it a 64bit arch or a 32bit with double-width
> instructions) but has an ABI that allows u32 alignment on them is daft.

Why ? For 64-bit data on 32-bit systems, hardware doesn't claim to provide any
single-copy atomicity for such data and software doesn't expect either.


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: single copy atomicity for double load/stores on 32-bit systems

[Vineet Gupta]

On 5/31/19 1:21 AM, Peter Zijlstra wrote:
>> I'm not sure how to interpret "natural alignment" for the case of double
>> load/stores on 32-bit systems where the hardware and ABI allow for 4 byte
>> alignment (ARCv2 LDD/STD, ARM LDRD/STRD )
> Natural alignment: !((uintptr_t)ptr % sizeof(*ptr))
>
> For any u64 type, that would give 8 byte alignment. the problem
> otherwise being that your data spans two lines/pages etc..

Sure, but as Paul said, if the software doesn't expect them to be atomic by
default, they could span 2 hardware lines to keep the implementation 
simpler/sane.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

RE: Pass config-time variable to LIBC_SLIBDIR_RTLDDIR

[Joseph Myers]

On Mon, 3 Jun 2019, Alexey Brodkin wrote:

> Well I'm trying to solve a little bit different problem - to build
> a universal multilib cross-toolchain which will be usable for building
> binaries optimized for different ARC cores. Different I mean:
>  - Binary-incompatible architecture generations: ARCv1/ARCv2 (both still 
> 32-bit)
>  - Hard/soft floating-point
>  - etc.

That sort of thing generally uses a separate sysroot for each multilib.  
(Using GCC's t-sysroot-suffix avoids needing to define SYSROOT_SUFFIX_SPEC 
manually yourself.)

Then the libraries don't need to use separate library directories if only 
one ABI makes sense on a target at a time.  (But cases with different 
endianness / different function calling ABI / different struct layout etc. 
should still use different dynamic linker names.)

> > Checking -mcpu in CC is a bad idea, given that the compiler might have
> > been configured with a default CPU rather than passing it on the command
> > line.
> 
> Well this case (no "-mcpu" in CC) is handled - then we just installed
> libs in default non-multilib location, i.e. simple "/lib".

The locations should be a function of the ABI - *not* of whether the ABI 
is the default one for the compiler.  (For example, /lib64 is the 
directory for non-x32 x86_64 libraries - both in an x86_64-linux-gnu 
toolchain, and also for the -m64 multilib of an i686-linux-gnu toolchain 
configured --enable-targets=all.  If you use Debian-style multiarch 
layout, the locations are still a function of the ABI, just a different 
function.)

-- 
Joseph S. Myers
jos...@codesourcery.com

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

RE: Pass config-time variable to LIBC_SLIBDIR_RTLDDIR

[Alexey Brodkin]

Hi Joseph,

> -Original Message-
> From: Joseph Myers 
> Sent: Monday, June 3, 2019 6:41 PM
> To: Alexey Brodkin 
> Cc: Andreas Schwab ; libc-al...@sourceware.org; 
> linux-snps-arc@lists.infradead.org
> Subject: Re: Pass config-time variable to LIBC_SLIBDIR_RTLDDIR
> 
> On Fri, 31 May 2019, Alexey Brodkin wrote:
> 
> > Hi Andreas,
> >
> > I'm trying to implement multilib support for ARC port of Glibc
> > and for that we seem to need to have unique slibdir/rtlddir pair per
> > each machine flavor. In our case these are at least:
> >  - ARC700 (legacy ARCompact architecture)
> >  - ARC HS38 (new gen ARCv2 architecture)
> >  - ARC HS38 with hardware floating-point
> >  - ARC HS48 (binary-compatible with HS38 but with different pipeline so
> >  compiler schedules instructions differently)
> 
> If two processors are binary-compatible, in general you wouldn't have
> different library directories.  (The HWCAP mechanism can be used to have a
> single dynamic linker search different directories for optimized libraries
> depending on the processor; put the relevant HWCAP bits in
> HWCAP_IMPORTANT.  And of course you can just install different library
> builds depending on the processor you'll be running the resulting OS on.)
> 
> Different library directories are intended for the case where binaries for
> different ABIs can be executed on the same system (e.g. 32-bit and 64-bit;
> https://sourceware.org/ml/libc-alpha/2018-01/msg8.html gives more
> details of the various places that need updating to support such a
> configuration in glibc).  For other cases of different ABIs, there should
> be different dynamic linker names, to support multiarch configurations
> that might run different-architecture binaries under emulation, but
> different library directories are not required.

Well I'm trying to solve a little bit different problem - to build
a universal multilib cross-toolchain which will be usable for building
binaries optimized for different ARC cores. Different I mean:
 - Binary-incompatible architecture generations: ARCv1/ARCv2 (both still 32-bit)
 - Hard/soft floating-point
 - etc.

GCC itself handles multilib perfectly fine as long as C library components
are installed in proper locations. And bare-metal toolchain with Newlib as
well as uClibc Linux toolchain are known to work as expected: C libraries
get installed to a subfolder referenced by "arc-linux-gcc -print-multi-lib".

As for Glibc at least in Crosstool-NG (the one and only toolchain builder
that supports multilib toolchains) Glibc's smarts are used for libs installation
in sysroot.

I think it used to be done similarly to Newlib & uClibc but then was
converted to a current state by this commit:
https://github.com/crosstool-ng/crosstool-ng/commit/43c303c946c61469181d633cd5620cb92e44c329

That said since I'm not yet interested in multiple libs on target
maybe I'm just looking at a wrong place and instead CT-NG should be
improved. Alexey Neyman (in CC) might have more to add here.

> > Given we have in GCC a dedicated "-mcpu" value for each of items above
> > my first thought was to "automatically" setup slibdir/rtlddir
> > based on "-mcpu" value passed in CC during configuration.
> 
> Checking -mcpu in CC is a bad idea, given that the compiler might have
> been configured with a default CPU rather than passing it on the command
> line.

Well this case (no "-mcpu" in CC) is handled - then we just installed
libs in default non-multilib location, i.e. simple "/lib".
 
> Rather, you should test how the compiler behaves: either run $CC $CFLAGS
> $CPPFLAGS -E -dM -xc /dev/null and extract and examine predefined macros,
> or use AC_EGREP_CPP or AC_COMPILE_IFELSE for the same purpose.  (If you
> don't have predefined macros that make all the required ABI distinctions,
> obviously you need to add them.)  There are various examples of this in
> existing configure / preconfigure fragments.

Right I did see a lot of those.

> Since there should be a finite list of known ABIs (which would be listed
> on https://sourceware.org/glibc/wiki/ABIList for a port included in
> glibc), you can then have a finite number of LIBC_SLIBDIR_RTLDDIR calls in
> a case statement.

Agree, but again this is more for run-time libs on target where having
many flavors of libs is quite an overkill.

-Alexey
 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] ARC: build: Try to guess CROSS_COMPILE with cc-cross-prefix

[Christoph Hellwig]

I wish we could just set CROSS_COMPILE and ARCH in .config.  That would
make everyones life compile testing on multiple architectures so much
easier.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

RE: [PATCH] ARC: build: Try to guess CROSS_COMPILE with cc-cross-prefix

[Alexey Brodkin]

Hi Vineet,

> -Original Message-
> From: Vineet Gupta 
> Sent: Monday, June 3, 2019 7:25 PM
> To: Alexey Brodkin ; linux-snps-arc@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org; Masahiro Yamada 
> 
> Subject: Re: [PATCH] ARC: build: Try to guess CROSS_COMPILE with 
> cc-cross-prefix
> 
> On 6/2/19 11:31 PM, Alexey Brodkin wrote:
> > For a long time we used to hard-code CROSS_COMPILE prefix
> > for ARC until it started to cause problems, so we decided to
> > solely rely on CROSS_COMPILE externally set by a user:
> > commit 40660f1fcee8 ("ARC: build: Don't set CROSS_COMPILE in arch's 
> > Makefile").
> >
> > While it works perfectly fine for build-systems where the prefix
> > gets defined anyways for us human beings it's quite an annoying
> > requirement especially given most of time the same one prefix
> > "arc-linux-" is all what we need.
> >
> > It looks like finally we're getting the best of both worlds:
> >  1. W/o cross-toolchain we still may install headers, build .dtb etc
> >  2. W/ cross-toolchain get the kerne built with only ARCH=arc
> >
> > Inspired by [1] & [2].
> >
> > [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-May/005788.html
> > [2] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc2b47b55f17
> >
> > A side note: even though "cc-cross-prefix" does its job it pollutes
> > console with output of "which" for all the prefixes it didn't manage to find
> > a matching cross-compiler for like that:
> > | # ARCH=arc make defconfig
> > | which: no arceb-linux-gcc in (~/.local/bin:~/bin:/usr/bin:/usr/sbin)
> > | *** Default configuration is based on 'nsim_hs_defconfig'
> >
> > Signed-off-by: Alexey Brodkin 
> > Cc: Masahiro Yamada 
> > Cc: Vineet Gupta 
> 
> Not a big deal but I'd propose we add "Suggested-by: vgupta" since that is 
> where
> it came from.

Ooops, indeed that should have been added, but instead I just
mentioned your earlier email in the mailing list.

Care to add yourself on patch application?

-Alexey


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] ARC: build: Try to guess CROSS_COMPILE with cc-cross-prefix

[Vineet Gupta]

On 6/2/19 11:31 PM, Alexey Brodkin wrote:
> For a long time we used to hard-code CROSS_COMPILE prefix
> for ARC until it started to cause problems, so we decided to
> solely rely on CROSS_COMPILE externally set by a user:
> commit 40660f1fcee8 ("ARC: build: Don't set CROSS_COMPILE in arch's 
> Makefile").
>
> While it works perfectly fine for build-systems where the prefix
> gets defined anyways for us human beings it's quite an annoying
> requirement especially given most of time the same one prefix
> "arc-linux-" is all what we need.
>
> It looks like finally we're getting the best of both worlds:
>  1. W/o cross-toolchain we still may install headers, build .dtb etc
>  2. W/ cross-toolchain get the kerne built with only ARCH=arc
>
> Inspired by [1] & [2].
>
> [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-May/005788.html
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc2b47b55f17
>
> A side note: even though "cc-cross-prefix" does its job it pollutes
> console with output of "which" for all the prefixes it didn't manage to find
> a matching cross-compiler for like that:
> | # ARCH=arc make defconfig
> | which: no arceb-linux-gcc in (~/.local/bin:~/bin:/usr/bin:/usr/sbin)
> | *** Default configuration is based on 'nsim_hs_defconfig'
>
> Signed-off-by: Alexey Brodkin 
> Cc: Masahiro Yamada 
> Cc: Vineet Gupta 

Not a big deal but I'd propose we add "Suggested-by: vgupta" since that is where
it came from.

@Masahiro san I suppose you are OK with this, so perhaps an Ack etc would be 
nice
to have.

Thx,
-Vineet

> ---
>  arch/arc/Makefile | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arc/Makefile b/arch/arc/Makefile
> index e2b991f75bc5..9cfd2ba7a12d 100644
> --- a/arch/arc/Makefile
> +++ b/arch/arc/Makefile
> @@ -8,6 +8,10 @@
>  
>  KBUILD_DEFCONFIG := nsim_hs_defconfig
>  
> +ifeq ($(CROSS_COMPILE),)
> +CROSS_COMPILE := $(call cc-cross-prefix, arc-linux- arceb-linux-)
> +endif
> +
>  cflags-y += -fno-common -pipe -fno-builtin -mmedium-calls -D__linux__
>  cflags-$(CONFIG_ISA_ARCOMPACT)   += -mA7
>  cflags-$(CONFIG_ISA_ARCV2)   += -mcpu=hs38


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: Pass config-time variable to LIBC_SLIBDIR_RTLDDIR

[Joseph Myers]

On Fri, 31 May 2019, Alexey Brodkin wrote:

> Hi Andreas,
> 
> I'm trying to implement multilib support for ARC port of Glibc
> and for that we seem to need to have unique slibdir/rtlddir pair per
> each machine flavor. In our case these are at least:
>  - ARC700 (legacy ARCompact architecture)
>  - ARC HS38 (new gen ARCv2 architecture)
>  - ARC HS38 with hardware floating-point
>  - ARC HS48 (binary-compatible with HS38 but with different pipeline so
>  compiler schedules instructions differently)

If two processors are binary-compatible, in general you wouldn't have 
different library directories.  (The HWCAP mechanism can be used to have a 
single dynamic linker search different directories for optimized libraries 
depending on the processor; put the relevant HWCAP bits in 
HWCAP_IMPORTANT.  And of course you can just install different library 
builds depending on the processor you'll be running the resulting OS on.)

Different library directories are intended for the case where binaries for 
different ABIs can be executed on the same system (e.g. 32-bit and 64-bit; 
 gives more 
details of the various places that need updating to support such a 
configuration in glibc).  For other cases of different ABIs, there should 
be different dynamic linker names, to support multiarch configurations 
that might run different-architecture binaries under emulation, but 
different library directories are not required.

> Given we have in GCC a dedicated "-mcpu" value for each of items above
> my first thought was to "automatically" setup slibdir/rtlddir
> based on "-mcpu" value passed in CC during configuration.

Checking -mcpu in CC is a bad idea, given that the compiler might have 
been configured with a default CPU rather than passing it on the command 
line.

Rather, you should test how the compiler behaves: either run $CC $CFLAGS 
$CPPFLAGS -E -dM -xc /dev/null and extract and examine predefined macros, 
or use AC_EGREP_CPP or AC_COMPILE_IFELSE for the same purpose.  (If you 
don't have predefined macros that make all the required ABI distinctions, 
obviously you need to add them.)  There are various examples of this in 
existing configure / preconfigure fragments.

Since there should be a finite list of known ABIs (which would be listed 
on  for a port included in 
glibc), you can then have a finite number of LIBC_SLIBDIR_RTLDDIR calls in 
a case statement.

-- 
Joseph S. Myers
jos...@codesourcery.com

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

RE: [PATCH] kbuild: use more portable 'command -v' for cc-cross-prefix

[David Laight]

From: Masahiro Yamada
> Sent: 03 June 2019 12:38
> Hi David,
> 
> On Mon, Jun 3, 2019 at 8:14 PM David Laight  wrote:
> >
> > From: Masahiro Yamada
> > > Sent: 03 June 2019 11:49
> > >
> > > To print the pathname that will be used by shell in the current
> > > environment, 'command -v' is a standardized way. [1]
> > >
> > > 'which' is also often used in scripting, but it is not portable.
> > >
> > > When I worked on commit bd55f96fa9fc ("kbuild: refactor cc-cross-prefix
> > > implementation"), I was eager to use 'command -v' but it did not work.
> > > (The reason is explained below.)
> > >
> > > I kept 'which' as before but got rid of '> /dev/null 2>&1' as I
> > > thought it was no longer needed. Sorry, I was wrong.
> > >
> > > It works well on my Ubuntu machine, but Alexey Brodkin reports annoying
> > > warnings from the 'which' on CentOS 7 when the given command is not
> > > found in the PATH environment.
> > >
> > >   $ which foo
> > >   which: no foo in 
> > > (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
> > >
> > > Given that behavior of 'which' is different on environment, I want
> > > to try 'command -v' again.
> > >
> > > The specification [1] clearly describes the behavior of 'command -v'
> > > when the given command is not found:
> > >
> > >   Otherwise, no output shall be written and the exit status shall reflect
> > >   that the name was not found.
> > >
> > > However, we need a little magic to use 'command -v' from Make.
> > >
> > > $(shell ...) passes the argument to a subshell for execution, and
> > > returns the standard output of the command.
> > >
> > > Here is a trick. GNU Make may optimize this by executing the command
> > > directly instead of forking a subshell, if no shell special characters
> > > are found in the command line and omitting the subshell will not
> > > change the behavior.
> > >
> > > In this case, no shell special character is used. So, Make will try
> > > to run the command directly. However, 'command' is a shell-builtin
> > > command. In fact, Make has a table of shell-builtin commands because
> > > it must spawn a subshell to execute them.
> > >
> > > Until recently, 'command' was missing in the table.
> > >
> > > This issue was fixed by the following commit:
> > >
> > > | commit 1af314465e5dfe3e8baa839a32a72e83c04f26ef
> > > | Author: Paul Smith 
> > > | Date:   Sun Nov 12 18:10:28 2017 -0500
> > > |
> > > | * job.c: Add "command" as a known shell built-in.
> > > |
> > > | This is not a POSIX shell built-in but it's common in UNIX shells.
> > > | Reported by Nick Bowler .
> > >
> > > This is not included in any released versions of Make yet.
> > > (But, some distributions may have back-ported the fix-up.)
> > >
> > > To trick Make and let it fork the subshell, I added a shell special
> > > character '~'. We may be able to get rid of this workaround someday,
> > > but it is very far into the future.
> > >
> > > [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html
> > >
> > > Fixes: bd55f96fa9fc ("kbuild: refactor cc-cross-prefix implementation")
> > > Cc: linux-stable  # 5.1
> > > Reported-by: Alexey Brodkin 
> > > Signed-off-by: Masahiro Yamada 
> > > ---
> > >
> > >  scripts/Kbuild.include | 5 -
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
> > > index 85d758233483..5a32ca80c3f6 100644
> > > --- a/scripts/Kbuild.include
> > > +++ b/scripts/Kbuild.include
> > > @@ -74,8 +74,11 @@ endef
> > >  # Usage: CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu- 
> > > m68k-linux-)
> > >  # Return first  where a gcc is found in PATH.
> > >  # If no gcc found in PATH with listed prefixes return nothing
> > > +#
> > > +# Note: the special character '~' forces Make to invoke a shell. This 
> > > workaround
> > > +# is needed because this issue was only fixed after GNU Make 4.2.1 
> > > release.
> > >  cc-cross-prefix = $(firstword $(foreach c, $(filter-out -%, $(1)), \
> > > - $(if $(shell which $(c)gcc), $(c
> > > + $(if $(shell command -v $(c)gcc ~), $(c
> >
> > I see a problem here:
> > command -v foo bar
> > could be deemed to be an error (extra argument).
> 
> OK, the specification does not allow to pass arguments
> with -v.
> 
> 
> > You could use:
> > $(shell sh -c "command -v $(c)gcc")
> > or maybe:
> > $(shell command$${x:+} -v $(c)gcc)
> 
> 
> How about this?
> 
>   $(shell : ~; command -v $(c)gcc)

Overcomplicated 

I've not looked at the list of 'special characters' in make,
but I suspect any variable expansion is enough.
Since ${x:+} always expands to the empty string (whether or
not 'x' is defined) it can't have any unfortunate side effects.

I'd comment as:
# Note: ${x:+} always expands to the empty string and forces all
# versions of make to actually exec $SHELL rather than try to
# directly execute the shell 

RE: [PATCH] kbuild: use more portable 'command -v' for cc-cross-prefix

[David Laight]

From: Masahiro Yamada
> Sent: 03 June 2019 12:45
> On Mon, Jun 3, 2019 at 8:16 PM David Laight  wrote:
> >
> > From: Masahiro Yamada
> > > Sent: 03 June 2019 11:49
> > >
> > > To print the pathname that will be used by shell in the current
> > > environment, 'command -v' is a standardized way. [1]
> > >
> > > 'which' is also often used in scripting, but it is not portable.
> >
> > All uses of 'which' should be expunged.
> > It is a bourne shell script that is trying to emulate a csh builtin.
> > It is doomed to fail in corner cases.
> > ISTR it has serious problems with shell functions and aliases.
> 
> OK, I do not have time to check it treewide.
> I expect somebody will contribute to it.
> 
> 
> 
> BTW, I see yet another way to get the command path.
> 
> 'type -path' is bash-specific.

'type' itself should be supported by all shells, but the output
format (esp for errors) probably varies.

> Maybe, we should do this too:
> 
> diff --git a/scripts/mkuboot.sh b/scripts/mkuboot.sh
> index 4b1fe09e9042..77829ee4268e 100755
> --- a/scripts/mkuboot.sh
> +++ b/scripts/mkuboot.sh
> @@ -1,14 +1,14 @@
> -#!/bin/bash
> +#!/bin/sh

/bin/sh might be 'dash' - which is just plain broken in so many ways.
Try (IIRC) ${foo%${foo#bar}}
It might even be the original SYSV /bin/sh which doesn't support $((expr))
or ${foo#bar} - but that may break too much, but $SHELL might fix it.

dash probably has the rather obscure bug in stripping '\n' from $(...)
output that I found and fixed in NetBSD's ash may years ago.
Try: foo="$(jot -b "" 130)"
All 130 '\n' should be deleted.
Mostly it fails to delete all the '\n', but it can remove extra ones!

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] kbuild: use more portable 'command -v' for cc-cross-prefix

[Masahiro Yamada]

On Mon, Jun 3, 2019 at 8:16 PM David Laight  wrote:
>
> From: Masahiro Yamada
> > Sent: 03 June 2019 11:49
> >
> > To print the pathname that will be used by shell in the current
> > environment, 'command -v' is a standardized way. [1]
> >
> > 'which' is also often used in scripting, but it is not portable.
>
> All uses of 'which' should be expunged.
> It is a bourne shell script that is trying to emulate a csh builtin.
> It is doomed to fail in corner cases.
> ISTR it has serious problems with shell functions and aliases.

OK, I do not have time to check it treewide.
I expect somebody will contribute to it.



BTW, I see yet another way to get the command path.

'type -path' is bash-specific.

Maybe, we should do this too:

diff --git a/scripts/mkuboot.sh b/scripts/mkuboot.sh
index 4b1fe09e9042..77829ee4268e 100755
--- a/scripts/mkuboot.sh
+++ b/scripts/mkuboot.sh
@@ -1,14 +1,14 @@
-#!/bin/bash
+#!/bin/sh
 # SPDX-License-Identifier: GPL-2.0

 #
 # Build U-Boot image when `mkimage' tool is available.
 #

-MKIMAGE=$(type -path "${CROSS_COMPILE}mkimage")
+MKIMAGE=$(command -v "${CROSS_COMPILE}mkimage")

 if [ -z "${MKIMAGE}" ]; then
-   MKIMAGE=$(type -path mkimage)
+   MKIMAGE=$(command -v mkimage)
if [ -z "${MKIMAGE}" ]; then
# Doesn't exist
echo '"mkimage" command not found - U-Boot images will
not be built' >&2


-- 
Best Regards
Masahiro Yamada

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] kbuild: use more portable 'command -v' for cc-cross-prefix

[Masahiro Yamada]

Hi David,

On Mon, Jun 3, 2019 at 8:14 PM David Laight  wrote:
>
> From: Masahiro Yamada
> > Sent: 03 June 2019 11:49
> >
> > To print the pathname that will be used by shell in the current
> > environment, 'command -v' is a standardized way. [1]
> >
> > 'which' is also often used in scripting, but it is not portable.
> >
> > When I worked on commit bd55f96fa9fc ("kbuild: refactor cc-cross-prefix
> > implementation"), I was eager to use 'command -v' but it did not work.
> > (The reason is explained below.)
> >
> > I kept 'which' as before but got rid of '> /dev/null 2>&1' as I
> > thought it was no longer needed. Sorry, I was wrong.
> >
> > It works well on my Ubuntu machine, but Alexey Brodkin reports annoying
> > warnings from the 'which' on CentOS 7 when the given command is not
> > found in the PATH environment.
> >
> >   $ which foo
> >   which: no foo in 
> > (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
> >
> > Given that behavior of 'which' is different on environment, I want
> > to try 'command -v' again.
> >
> > The specification [1] clearly describes the behavior of 'command -v'
> > when the given command is not found:
> >
> >   Otherwise, no output shall be written and the exit status shall reflect
> >   that the name was not found.
> >
> > However, we need a little magic to use 'command -v' from Make.
> >
> > $(shell ...) passes the argument to a subshell for execution, and
> > returns the standard output of the command.
> >
> > Here is a trick. GNU Make may optimize this by executing the command
> > directly instead of forking a subshell, if no shell special characters
> > are found in the command line and omitting the subshell will not
> > change the behavior.
> >
> > In this case, no shell special character is used. So, Make will try
> > to run the command directly. However, 'command' is a shell-builtin
> > command. In fact, Make has a table of shell-builtin commands because
> > it must spawn a subshell to execute them.
> >
> > Until recently, 'command' was missing in the table.
> >
> > This issue was fixed by the following commit:
> >
> > | commit 1af314465e5dfe3e8baa839a32a72e83c04f26ef
> > | Author: Paul Smith 
> > | Date:   Sun Nov 12 18:10:28 2017 -0500
> > |
> > | * job.c: Add "command" as a known shell built-in.
> > |
> > | This is not a POSIX shell built-in but it's common in UNIX shells.
> > | Reported by Nick Bowler .
> >
> > This is not included in any released versions of Make yet.
> > (But, some distributions may have back-ported the fix-up.)
> >
> > To trick Make and let it fork the subshell, I added a shell special
> > character '~'. We may be able to get rid of this workaround someday,
> > but it is very far into the future.
> >
> > [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html
> >
> > Fixes: bd55f96fa9fc ("kbuild: refactor cc-cross-prefix implementation")
> > Cc: linux-stable  # 5.1
> > Reported-by: Alexey Brodkin 
> > Signed-off-by: Masahiro Yamada 
> > ---
> >
> >  scripts/Kbuild.include | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
> > index 85d758233483..5a32ca80c3f6 100644
> > --- a/scripts/Kbuild.include
> > +++ b/scripts/Kbuild.include
> > @@ -74,8 +74,11 @@ endef
> >  # Usage: CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu- 
> > m68k-linux-)
> >  # Return first  where a gcc is found in PATH.
> >  # If no gcc found in PATH with listed prefixes return nothing
> > +#
> > +# Note: the special character '~' forces Make to invoke a shell. This 
> > workaround
> > +# is needed because this issue was only fixed after GNU Make 4.2.1 release.
> >  cc-cross-prefix = $(firstword $(foreach c, $(filter-out -%, $(1)), \
> > - $(if $(shell which $(c)gcc), $(c
> > + $(if $(shell command -v $(c)gcc ~), $(c
>
> I see a problem here:
> command -v foo bar
> could be deemed to be an error (extra argument).

OK, the specification does not allow to pass arguments
with -v.


> You could use:
> $(shell sh -c "command -v $(c)gcc")
> or maybe:
> $(shell command$${x:+} -v $(c)gcc)


How about this?

  $(shell : ~; command -v $(c)gcc)



-- 
Best Regards
Masahiro Yamada

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

RE: [PATCH] kbuild: use more portable 'command -v' for cc-cross-prefix

[David Laight]

From: Masahiro Yamada
> Sent: 03 June 2019 11:49
> 
> To print the pathname that will be used by shell in the current
> environment, 'command -v' is a standardized way. [1]
> 
> 'which' is also often used in scripting, but it is not portable.

All uses of 'which' should be expunged.
It is a bourne shell script that is trying to emulate a csh builtin.
It is doomed to fail in corner cases.
ISTR it has serious problems with shell functions and aliases.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

RE: [PATCH] kbuild: use more portable 'command -v' for cc-cross-prefix

[David Laight]

From: Masahiro Yamada
> Sent: 03 June 2019 11:49
> 
> To print the pathname that will be used by shell in the current
> environment, 'command -v' is a standardized way. [1]
> 
> 'which' is also often used in scripting, but it is not portable.
> 
> When I worked on commit bd55f96fa9fc ("kbuild: refactor cc-cross-prefix
> implementation"), I was eager to use 'command -v' but it did not work.
> (The reason is explained below.)
> 
> I kept 'which' as before but got rid of '> /dev/null 2>&1' as I
> thought it was no longer needed. Sorry, I was wrong.
> 
> It works well on my Ubuntu machine, but Alexey Brodkin reports annoying
> warnings from the 'which' on CentOS 7 when the given command is not
> found in the PATH environment.
> 
>   $ which foo
>   which: no foo in 
> (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
> 
> Given that behavior of 'which' is different on environment, I want
> to try 'command -v' again.
> 
> The specification [1] clearly describes the behavior of 'command -v'
> when the given command is not found:
> 
>   Otherwise, no output shall be written and the exit status shall reflect
>   that the name was not found.
> 
> However, we need a little magic to use 'command -v' from Make.
> 
> $(shell ...) passes the argument to a subshell for execution, and
> returns the standard output of the command.
> 
> Here is a trick. GNU Make may optimize this by executing the command
> directly instead of forking a subshell, if no shell special characters
> are found in the command line and omitting the subshell will not
> change the behavior.
> 
> In this case, no shell special character is used. So, Make will try
> to run the command directly. However, 'command' is a shell-builtin
> command. In fact, Make has a table of shell-builtin commands because
> it must spawn a subshell to execute them.
> 
> Until recently, 'command' was missing in the table.
> 
> This issue was fixed by the following commit:
> 
> | commit 1af314465e5dfe3e8baa839a32a72e83c04f26ef
> | Author: Paul Smith 
> | Date:   Sun Nov 12 18:10:28 2017 -0500
> |
> | * job.c: Add "command" as a known shell built-in.
> |
> | This is not a POSIX shell built-in but it's common in UNIX shells.
> | Reported by Nick Bowler .
> 
> This is not included in any released versions of Make yet.
> (But, some distributions may have back-ported the fix-up.)
> 
> To trick Make and let it fork the subshell, I added a shell special
> character '~'. We may be able to get rid of this workaround someday,
> but it is very far into the future.
> 
> [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html
> 
> Fixes: bd55f96fa9fc ("kbuild: refactor cc-cross-prefix implementation")
> Cc: linux-stable  # 5.1
> Reported-by: Alexey Brodkin 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  scripts/Kbuild.include | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
> index 85d758233483..5a32ca80c3f6 100644
> --- a/scripts/Kbuild.include
> +++ b/scripts/Kbuild.include
> @@ -74,8 +74,11 @@ endef
>  # Usage: CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu- 
> m68k-linux-)
>  # Return first  where a gcc is found in PATH.
>  # If no gcc found in PATH with listed prefixes return nothing
> +#
> +# Note: the special character '~' forces Make to invoke a shell. This 
> workaround
> +# is needed because this issue was only fixed after GNU Make 4.2.1 release.
>  cc-cross-prefix = $(firstword $(foreach c, $(filter-out -%, $(1)), \
> - $(if $(shell which $(c)gcc), $(c
> + $(if $(shell command -v $(c)gcc ~), $(c

I see a problem here:
command -v foo bar
could be deemed to be an error (extra argument).

You could use:
$(shell sh -c "command -v $(c)gcc")
or maybe:
$(shell command$${x:+} -v $(c)gcc)

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

RE: [PATCH] kbuild: use more portable 'command -v' for cc-cross-prefix

[Alexey Brodkin]

Hi Masahiro-san,

> -Original Message-
> From: linux-snps-arc  On Behalf 
> Of Masahiro Yamada
> Sent: Monday, June 3, 2019 1:49 PM
> To: linux-kbu...@vger.kernel.org
> Cc: Michal Marek ; Vineet Gupta 
> ; Alexey Brodkin
> ; linux-ker...@vger.kernel.org; linux-stable 
> ; Masahiro
> Yamada ; linux-snps-arc@lists.infradead.org
> Subject: [PATCH] kbuild: use more portable 'command -v' for cc-cross-prefix

[snip]
 
> Fixes: bd55f96fa9fc ("kbuild: refactor cc-cross-prefix implementation")
> Cc: linux-stable  # 5.1
> Reported-by: Alexey Brodkin 
> Signed-off-by: Masahiro Yamada 
> ---

Thanks for the prompt fix - it does the trick, now no junk in the console!

Tested-by: Alexey Brodkin 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH] kbuild: use more portable 'command -v' for cc-cross-prefix

[Masahiro Yamada]

To print the pathname that will be used by shell in the current
environment, 'command -v' is a standardized way. [1]

'which' is also often used in scripting, but it is not portable.

When I worked on commit bd55f96fa9fc ("kbuild: refactor cc-cross-prefix
implementation"), I was eager to use 'command -v' but it did not work.
(The reason is explained below.)

I kept 'which' as before but got rid of '> /dev/null 2>&1' as I
thought it was no longer needed. Sorry, I was wrong.

It works well on my Ubuntu machine, but Alexey Brodkin reports annoying
warnings from the 'which' on CentOS 7 when the given command is not
found in the PATH environment.

  $ which foo
  which: no foo in 
(/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)

Given that behavior of 'which' is different on environment, I want
to try 'command -v' again.

The specification [1] clearly describes the behavior of 'command -v'
when the given command is not found:

  Otherwise, no output shall be written and the exit status shall reflect
  that the name was not found.

However, we need a little magic to use 'command -v' from Make.

$(shell ...) passes the argument to a subshell for execution, and
returns the standard output of the command.

Here is a trick. GNU Make may optimize this by executing the command
directly instead of forking a subshell, if no shell special characters
are found in the command line and omitting the subshell will not
change the behavior.

In this case, no shell special character is used. So, Make will try
to run the command directly. However, 'command' is a shell-builtin
command. In fact, Make has a table of shell-builtin commands because
it must spawn a subshell to execute them.

Until recently, 'command' was missing in the table.

This issue was fixed by the following commit:

| commit 1af314465e5dfe3e8baa839a32a72e83c04f26ef
| Author: Paul Smith 
| Date:   Sun Nov 12 18:10:28 2017 -0500
|
| * job.c: Add "command" as a known shell built-in.
|
| This is not a POSIX shell built-in but it's common in UNIX shells.
| Reported by Nick Bowler .

This is not included in any released versions of Make yet.
(But, some distributions may have back-ported the fix-up.)

To trick Make and let it fork the subshell, I added a shell special
character '~'. We may be able to get rid of this workaround someday,
but it is very far into the future.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html

Fixes: bd55f96fa9fc ("kbuild: refactor cc-cross-prefix implementation")
Cc: linux-stable  # 5.1
Reported-by: Alexey Brodkin 
Signed-off-by: Masahiro Yamada 
---

 scripts/Kbuild.include | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 85d758233483..5a32ca80c3f6 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -74,8 +74,11 @@ endef
 # Usage: CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu- m68k-linux-)
 # Return first  where a gcc is found in PATH.
 # If no gcc found in PATH with listed prefixes return nothing
+#
+# Note: the special character '~' forces Make to invoke a shell. This 
workaround
+# is needed because this issue was only fixed after GNU Make 4.2.1 release.
 cc-cross-prefix = $(firstword $(foreach c, $(filter-out -%, $(1)), \
-   $(if $(shell which $(c)gcc), $(c
+   $(if $(shell command -v $(c)gcc ~), $(c
 
 # output directory for tests below
 TMPOUT := $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/)
-- 
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: build: Try to guess CROSS_COMPILE with cc-cross-prefix

[Masahiro Yamada]

Hi Alexey,

On Mon, Jun 3, 2019 at 5:34 PM Alexey Brodkin
 wrote:
>
> Hi Masahiro-san,
>
> > -Original Message-
> > From: Masahiro Yamada 
> > Sent: Monday, June 3, 2019 11:18 AM
> > To: Alexey Brodkin 
> > Cc: arcml ; Linux Kernel Mailing List 
> >  > ker...@vger.kernel.org>; Vineet Gupta 
> > Subject: Re: [PATCH] ARC: build: Try to guess CROSS_COMPILE with 
> > cc-cross-prefix
> >
> > Hi Alexey,
> >
> > On Mon, Jun 3, 2019 at 3:42 PM Alexey Brodkin
> >  wrote:
>
> [snip]
>
> > > A side note: even though "cc-cross-prefix" does its job it pollutes
> > > console with output of "which" for all the prefixes it didn't manage to 
> > > find
> > > a matching cross-compiler for like that:
> > > | # ARCH=arc make defconfig
> > > | which: no arceb-linux-gcc in (~/.local/bin:~/bin:/usr/bin:/usr/sbin)
> > > | *** Default configuration is based on 'nsim_hs_defconfig'
> >
> >
> > Oh really?
> >
> > masahiro@pug:~$ which arc-linux-gcc
> > /home/masahiro/tools/arc/bin/arc-linux-gcc
> > masahiro@pug:~$ which dummy-linux-gcc
> > masahiro@pug:~$ echo $?
> > 1
> >
> >
> > When 'which' cannot find the given command,
> > it does not print anything to stderr.
> >
> > Does it work differently on your machine?
>
> Well on Ubuntu 18.04 indeed which doesn't show anything
> but on my build-server with CentOS 7 I'm getting mentioned verbose output:
> | # cat /etc/redhat-release
> | CentOS Linux release 7.3.1611 (Core)
>
> | # /usr/bin/which -v
> | GNU which v2.20, Copyright (C) 1999 - 2008 Carlo Wood.
> | GNU which comes with ABSOLUTELY NO WARRANTY;
> | This program is free software; your freedom to use, change
> | and distribute this program is protected by the GPL.


OK, confirmed.

Probably using 'which' is a bad idea
since this is not portable.

I will send a fix-up patch soon.



-- 
Best Regards
Masahiro Yamada

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

RE: [PATCH] ARC: build: Try to guess CROSS_COMPILE with cc-cross-prefix

[Alexey Brodkin]

Hi Masahiro-san,

> -Original Message-
> From: Masahiro Yamada 
> Sent: Monday, June 3, 2019 11:18 AM
> To: Alexey Brodkin 
> Cc: arcml ; Linux Kernel Mailing List 
>  ker...@vger.kernel.org>; Vineet Gupta 
> Subject: Re: [PATCH] ARC: build: Try to guess CROSS_COMPILE with 
> cc-cross-prefix
> 
> Hi Alexey,
> 
> On Mon, Jun 3, 2019 at 3:42 PM Alexey Brodkin
>  wrote:

[snip]

> > A side note: even though "cc-cross-prefix" does its job it pollutes
> > console with output of "which" for all the prefixes it didn't manage to find
> > a matching cross-compiler for like that:
> > | # ARCH=arc make defconfig
> > | which: no arceb-linux-gcc in (~/.local/bin:~/bin:/usr/bin:/usr/sbin)
> > | *** Default configuration is based on 'nsim_hs_defconfig'
> 
> 
> Oh really?
> 
> masahiro@pug:~$ which arc-linux-gcc
> /home/masahiro/tools/arc/bin/arc-linux-gcc
> masahiro@pug:~$ which dummy-linux-gcc
> masahiro@pug:~$ echo $?
> 1
> 
> 
> When 'which' cannot find the given command,
> it does not print anything to stderr.
> 
> Does it work differently on your machine?

Well on Ubuntu 18.04 indeed which doesn't show anything
but on my build-server with CentOS 7 I'm getting mentioned verbose output:
| # cat /etc/redhat-release
| CentOS Linux release 7.3.1611 (Core)

| # /usr/bin/which -v
| GNU which v2.20, Copyright (C) 1999 - 2008 Carlo Wood.
| GNU which comes with ABSOLUTELY NO WARRANTY;
| This program is free software; your freedom to use, change
| and distribute this program is protected by the GPL.

-Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: Pass config-time variable to LIBC_SLIBDIR_RTLDDIR

[Andreas Schwab]

On Mai 31 2019, Alexey Brodkin  wrote:

> I guess mentioned change is not supposed to be reverted but then
> how do you think it's possible [if at all] to implement that kind of
> "automatic" setup of slibdir/rtlddir?

As the commit message says, you can reference makefile variables in the
value.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] ARC: build: Try to guess CROSS_COMPILE with cc-cross-prefix

[Masahiro Yamada]

Hi Alexey,

On Mon, Jun 3, 2019 at 3:42 PM Alexey Brodkin
 wrote:
>
> For a long time we used to hard-code CROSS_COMPILE prefix
> for ARC until it started to cause problems, so we decided to
> solely rely on CROSS_COMPILE externally set by a user:
> commit 40660f1fcee8 ("ARC: build: Don't set CROSS_COMPILE in arch's 
> Makefile").
>
> While it works perfectly fine for build-systems where the prefix
> gets defined anyways for us human beings it's quite an annoying
> requirement especially given most of time the same one prefix
> "arc-linux-" is all what we need.
>
> It looks like finally we're getting the best of both worlds:
>  1. W/o cross-toolchain we still may install headers, build .dtb etc
>  2. W/ cross-toolchain get the kerne built with only ARCH=arc
>
> Inspired by [1] & [2].
>
> [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-May/005788.html
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc2b47b55f17
>
> A side note: even though "cc-cross-prefix" does its job it pollutes
> console with output of "which" for all the prefixes it didn't manage to find
> a matching cross-compiler for like that:
> | # ARCH=arc make defconfig
> | which: no arceb-linux-gcc in (~/.local/bin:~/bin:/usr/bin:/usr/sbin)
> | *** Default configuration is based on 'nsim_hs_defconfig'


Oh really?

masahiro@pug:~$ which arc-linux-gcc
/home/masahiro/tools/arc/bin/arc-linux-gcc
masahiro@pug:~$ which dummy-linux-gcc
masahiro@pug:~$ echo $?
1


When 'which' cannot find the given command,
it does not print anything to stderr.

Does it work differently on your machine?




-- 
Best Regards
Masahiro Yamada

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH] ARC: build: Try to guess CROSS_COMPILE with cc-cross-prefix

[Alexey Brodkin]

For a long time we used to hard-code CROSS_COMPILE prefix
for ARC until it started to cause problems, so we decided to
solely rely on CROSS_COMPILE externally set by a user:
commit 40660f1fcee8 ("ARC: build: Don't set CROSS_COMPILE in arch's Makefile").

While it works perfectly fine for build-systems where the prefix
gets defined anyways for us human beings it's quite an annoying
requirement especially given most of time the same one prefix
"arc-linux-" is all what we need.

It looks like finally we're getting the best of both worlds:
 1. W/o cross-toolchain we still may install headers, build .dtb etc
 2. W/ cross-toolchain get the kerne built with only ARCH=arc

Inspired by [1] & [2].

[1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-May/005788.html
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc2b47b55f17

A side note: even though "cc-cross-prefix" does its job it pollutes
console with output of "which" for all the prefixes it didn't manage to find
a matching cross-compiler for like that:
| # ARCH=arc make defconfig
| which: no arceb-linux-gcc in (~/.local/bin:~/bin:/usr/bin:/usr/sbin)
| *** Default configuration is based on 'nsim_hs_defconfig'

Signed-off-by: Alexey Brodkin 
Cc: Masahiro Yamada 
Cc: Vineet Gupta 
---
 arch/arc/Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index e2b991f75bc5..9cfd2ba7a12d 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -8,6 +8,10 @@
 
 KBUILD_DEFCONFIG := nsim_hs_defconfig
 
+ifeq ($(CROSS_COMPILE),)
+CROSS_COMPILE := $(call cc-cross-prefix, arc-linux- arceb-linux-)
+endif
+
 cflags-y   += -fno-common -pipe -fno-builtin -mmedium-calls -D__linux__
 cflags-$(CONFIG_ISA_ARCOMPACT) += -mA7
 cflags-$(CONFIG_ISA_ARCV2) += -mcpu=hs38
-- 
2.16.2


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc