Hi Tony,
would it be possible to provide an arm64 cross-compiler on https://www.kernel.org/pub/tools/crosstool/ ?
Also, the xtensa compiler fails for me with an odd error message on one of my servers.
Have you heard about any problems with it from others ?
c6x is supposed to be supported by gcc now. No idea if that helps anything, though.
Thanks,
Guenter
Hi Guenter,
On Thu, Aug 15, 2013 at 1:07 PM, Guenter Roeck <[email protected]> wrote:
> Also, the xtensa compiler fails for me with an odd error message on one of
> my servers.
What is the message?
> Have you heard about any problems with it from others ?
Yes, xtensa compiler/linker is known to have issues with link-time
relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX.
--
Thanks.
-- Max
On 08/15/2013 02:46 AM, Max Filippov wrote:
> Hi Guenter,
>
> On Thu, Aug 15, 2013 at 1:07 PM, Guenter Roeck <[email protected]> wrote:
>> Also, the xtensa compiler fails for me with an odd error message on one of
>> my servers.
>
> What is the message?
>
It complains about being unable to change the byte order in an object file.
Actually, the message is from the linker, but I have no idea what is causing it.
It works on two servers but fails on the third. At least in theory the installation
on all servers should be the same.
Guenter
On Thu, Aug 15, 2013 at 6:02 PM, Guenter Roeck <[email protected]> wrote:
> On 08/15/2013 02:46 AM, Max Filippov wrote:
>>
>> Hi Guenter,
>>
>> On Thu, Aug 15, 2013 at 1:07 PM, Guenter Roeck <[email protected]> wrote:
>>>
>>> Also, the xtensa compiler fails for me with an odd error message on one
>>> of
>>> my servers.
>>
>>
>> What is the message?
>>
> It complains about being unable to change the byte order in an object file.
>
> Actually, the message is from the linker, but I have no idea what is causing
> it.
I've seen such message when I attempted to link a kernel, parts of which
were by mistake compiled for different xtensa core variants. Clean rebuild
fixed that.
> It works on two servers but fails on the third. At least in theory the
> installation
> on all servers should be the same.
--
Thanks.
-- Max
On 08/15/2013 07:22 AM, Max Filippov wrote:
> On Thu, Aug 15, 2013 at 6:02 PM, Guenter Roeck <[email protected]> wrote:
>> On 08/15/2013 02:46 AM, Max Filippov wrote:
>>>
>>> Hi Guenter,
>>>
>>> On Thu, Aug 15, 2013 at 1:07 PM, Guenter Roeck <[email protected]> wrote:
>>>>
>>>> Also, the xtensa compiler fails for me with an odd error message on one
>>>> of
>>>> my servers.
>>>
>>>
>>> What is the message?
>>>
>> It complains about being unable to change the byte order in an object file.
>>
>> Actually, the message is from the linker, but I have no idea what is causing
>> it.
>
> I've seen such message when I attempted to link a kernel, parts of which
> were by mistake compiled for different xtensa core variants. Clean rebuild
> fixed that.
>
"clean -f -q -d -x" did not help in my case. It can't get much cleaner than that.
Guenter
On Thu, Aug 15, 2013 at 02:07:05AM -0700, Guenter Roeck wrote:
> Hi Tony,
>
> would it be possible to provide an arm64 cross-compiler on https://www.kernel.org/pub/tools/crosstool/ ?
I have one built I just need to upload it. I'll try and do it this
weekend.
> Also, the xtensa compiler fails for me with an odd error message on one of my servers.
> Have you heard about any problems with it from others ?
Nope. Sorry, but it looks like you're being looked after there.
> c6x is supposed to be supported by gcc now. No idea if that helps anything, though.
Thanks. I have tried to build a 4.8.1 cx6 toolchain but It hasn't
worked todate. I'll keep trying as time permits.
>
> Thanks,
> Guenter
>
Yours Tony
On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote:
> Yes, xtensa compiler/linker is known to have issues with link-time
> relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX.
Is there something I can do at linker build time to help with this?
Yours Tony
On Fri, Aug 16, 2013 at 9:48 AM, Tony Breeds <[email protected]> wrote:
> On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote:
>
>> Yes, xtensa compiler/linker is known to have issues with link-time
>> relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX.
>
> Is there something I can do at linker build time to help with this?
I don't think so. Apparently it's not a linker configuration issue, it's a bug.
--
Thanks.
-- Max
On 08/16/2013 12:22 AM, Max Filippov wrote:
> On Fri, Aug 16, 2013 at 9:48 AM, Tony Breeds <[email protected]> wrote:
>> On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote:
>>
>>> Yes, xtensa compiler/linker is known to have issues with link-time
>>> relaxation; e.g. it may fail to build linux image without CONFIG_LD_NO_RELAX.
>>
>> Is there something I can do at linker build time to help with this?
>
> I don't think so. Apparently it's not a linker configuration issue, it's a bug.
>
CONFIG_LD_NO_RELAX doesn't help.
For reference, here is the error:
xtensa-linux-objcopy: Unable to change endianness of input file(s)
make[2]: *** [arch/xtensa/boot/boot-elf/Image.o] Error 1
make[1]: *** [boot-elf] Error 2
make: *** [zImage] Error 2
Oddly enough, I only see the problem on one of three servers.
Guenter
On 08/15/2013 10:47 PM, Tony Breeds wrote:
> On Thu, Aug 15, 2013 at 02:07:05AM -0700, Guenter Roeck wrote:
>> Hi Tony,
>>
>> would it be possible to provide an arm64 cross-compiler on https://www.kernel.org/pub/tools/crosstool/ ?
>
> I have one built I just need to upload it. I'll try and do it this
> weekend.
>
Would be great.
>> Also, the xtensa compiler fails for me with an odd error message on one of my servers.
>> Have you heard about any problems with it from others ?
>
> Nope. Sorry, but it looks like you're being looked after there.
>
No far not helping. I had hoped it is a known problem that has been fixed with a later
gcc or binutils version, but it looks like it isn't widely seen.
>> c6x is supposed to be supported by gcc now. No idea if that helps anything, though.
>
> Thanks. I have tried to build a 4.8.1 cx6 toolchain but It hasn't
> worked todate. I'll keep trying as time permits.
Too bad. Thanks for trying!
Guenter
On Fri, Aug 16, 2013 at 11:50 AM, Guenter Roeck <[email protected]> wrote:
> On 08/16/2013 12:22 AM, Max Filippov wrote:
>>
>> On Fri, Aug 16, 2013 at 9:48 AM, Tony Breeds <[email protected]>
>> wrote:
>>>
>>> On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote:
>>>
>>>> Yes, xtensa compiler/linker is known to have issues with link-time
>>>> relaxation; e.g. it may fail to build linux image without
>>>> CONFIG_LD_NO_RELAX.
>>>
>>>
>>> Is there something I can do at linker build time to help with this?
>>
>>
>> I don't think so. Apparently it's not a linker configuration issue, it's a
>> bug.
>>
> CONFIG_LD_NO_RELAX doesn't help.
>
> For reference, here is the error:
>
> xtensa-linux-objcopy: Unable to change endianness of input file(s)
> make[2]: *** [arch/xtensa/boot/boot-elf/Image.o] Error 1
> make[1]: *** [boot-elf] Error 2
> make: *** [zImage] Error 2
>
> Oddly enough, I only see the problem on one of three servers.
Guenter,
can you share a complete build log with V=1?
--
Thanks.
-- Max
On 08/16/2013 01:31 AM, Max Filippov wrote:
> On Fri, Aug 16, 2013 at 11:50 AM, Guenter Roeck <[email protected]> wrote:
>> On 08/16/2013 12:22 AM, Max Filippov wrote:
>>>
>>> On Fri, Aug 16, 2013 at 9:48 AM, Tony Breeds <[email protected]>
>>> wrote:
>>>>
>>>> On Thu, Aug 15, 2013 at 01:46:16PM +0400, Max Filippov wrote:
>>>>
>>>>> Yes, xtensa compiler/linker is known to have issues with link-time
>>>>> relaxation; e.g. it may fail to build linux image without
>>>>> CONFIG_LD_NO_RELAX.
>>>>
>>>>
>>>> Is there something I can do at linker build time to help with this?
>>>
>>>
>>> I don't think so. Apparently it's not a linker configuration issue, it's a
>>> bug.
>>>
>> CONFIG_LD_NO_RELAX doesn't help.
>>
>> For reference, here is the error:
>>
>> xtensa-linux-objcopy: Unable to change endianness of input file(s)
>> make[2]: *** [arch/xtensa/boot/boot-elf/Image.o] Error 1
>> make[1]: *** [boot-elf] Error 2
>> make: *** [zImage] Error 2
>>
>> Oddly enough, I only see the problem on one of three servers.
>
> Guenter,
> can you share a complete build log with V=1?
>
http://roeck-us.net/linux/logs/make.xtensa.log.bad
http://roeck-us.net/linux/logs/make.xtensa.log.ok
Key difference: the failing command in the bad case is
xtensa-linux-objcopy -O elf32-xtensa-le
and in the good case
xtensa-linux-objcopy -O elf32-xtensa-be
Same compiler (4.6.3 from kernel.org), same configuration file, same command line.
Configuration file is generated from defconfig, and the resulting .config file
is the same in both cases.
If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as parameter to it,
it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails.
I am puzzled. Guess there must be something different, but I have no idea what it might be.
If I execute the command which sets BIG_ENDIAN manually from the shell (from
arch/xtensa/boot/Makefile), it returns 1 on both systems.
If you have an idea what is going on please let me know.
Thanks,
Guenter
>> Guenter,
>> can you share a complete build log with V=1?
>>
>
> http://roeck-us.net/linux/logs/make.xtensa.log.bad
> http://roeck-us.net/linux/logs/make.xtensa.log.ok
>
> Key difference: the failing command in the bad case is
> xtensa-linux-objcopy -O elf32-xtensa-le
> and in the good case
> xtensa-linux-objcopy -O elf32-xtensa-be
>
> Same compiler (4.6.3 from kernel.org), same configuration file, same command
> line.
> Configuration file is generated from defconfig, and the resulting .config
> file
> is the same in both cases.
>
> If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as
> parameter to it,
> it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails.
>
> I am puzzled. Guess there must be something different, but I have no idea
> what it might be.
What is the output of
echo -e __XTENSA_EB__ | xtensa-linux-gcc -E -
on the failing system?
--
Thanks.
-- Max
On 08/16/2013 02:45 AM, Max Filippov wrote:
>>> Guenter,
>>> can you share a complete build log with V=1?
>>>
>>
>> http://roeck-us.net/linux/logs/make.xtensa.log.bad
>> http://roeck-us.net/linux/logs/make.xtensa.log.ok
>>
>> Key difference: the failing command in the bad case is
>> xtensa-linux-objcopy -O elf32-xtensa-le
>> and in the good case
>> xtensa-linux-objcopy -O elf32-xtensa-be
>>
>> Same compiler (4.6.3 from kernel.org), same configuration file, same command
>> line.
>> Configuration file is generated from defconfig, and the resulting .config
>> file
>> is the same in both cases.
>>
>> If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as
>> parameter to it,
>> it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails.
>>
>> I am puzzled. Guess there must be something different, but I have no idea
>> what it might be.
>
> What is the output of
>
> echo -e __XTENSA_EB__ | xtensa-linux-gcc -E -
>
> on the failing system?
>
It is "1", but that let me pinpoint the problem.
On the failing system, the version of echo executed by make does
not understand the "-e" option. Thus, when running arch/xtensa/boot/Makefile,
"echo -e __XTENSA_EB__" returns "-e __XTENSA_EB__", which doesn't compile,
and BIG_ENDIAN ends up being 0. So the compiler is completely innocent.
I found out the root source: SHELL is set the /bin/sh, which on the failing
system points to /bin/dash (default in Ubuntu, or at least it used to be).
dash apparently has a built-in version of echo which does not understand '-e'.
Oh well.
Thanks a lot for helping me to track this down!
Guenter
On Fri, Aug 16, 2013 at 08:43:35AM -0700, Guenter Roeck wrote:
> On 08/16/2013 02:45 AM, Max Filippov wrote:
>>>> Guenter,
>>>> can you share a complete build log with V=1?
>>>>
>>>
>>> http://roeck-us.net/linux/logs/make.xtensa.log.bad
>>> http://roeck-us.net/linux/logs/make.xtensa.log.ok
>>>
>>> Key difference: the failing command in the bad case is
>>> xtensa-linux-objcopy -O elf32-xtensa-le
>>> and in the good case
>>> xtensa-linux-objcopy -O elf32-xtensa-be
>>>
>>> Same compiler (4.6.3 from kernel.org), same configuration file, same command
>>> line.
>>> Configuration file is generated from defconfig, and the resulting .config
>>> file
>>> is the same in both cases.
>>>
>>> If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as
>>> parameter to it,
>>> it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails.
>>>
>>> I am puzzled. Guess there must be something different, but I have no idea
>>> what it might be.
>>
>> What is the output of
>>
>> echo -e __XTENSA_EB__ | xtensa-linux-gcc -E -
>>
>> on the failing system?
>>
> It is "1", but that let me pinpoint the problem.
>
> On the failing system, the version of echo executed by make does
> not understand the "-e" option. Thus, when running arch/xtensa/boot/Makefile,
> "echo -e __XTENSA_EB__" returns "-e __XTENSA_EB__", which doesn't compile,
> and BIG_ENDIAN ends up being 0. So the compiler is completely innocent.
>
> I found out the root source: SHELL is set the /bin/sh, which on the failing
> system points to /bin/dash (default in Ubuntu, or at least it used to be).
> dash apparently has a built-in version of echo which does not understand '-e'.
Could you try to replace "echo -e bla" with "printf "bla".
Kbuild.include uses some similar tricks but here printf is used.
Maybe this can be dash compatible then
Sam
On Fri, Aug 16, 2013 at 7:43 PM, Guenter Roeck <[email protected]> wrote:
> On 08/16/2013 02:45 AM, Max Filippov wrote:
>>>>
>>>> Guenter,
>>>> can you share a complete build log with V=1?
>>>>
>>>
>>> http://roeck-us.net/linux/logs/make.xtensa.log.bad
>>> http://roeck-us.net/linux/logs/make.xtensa.log.ok
>>>
>>> Key difference: the failing command in the bad case is
>>> xtensa-linux-objcopy -O elf32-xtensa-le
>>> and in the good case
>>> xtensa-linux-objcopy -O elf32-xtensa-be
>>>
>>> Same compiler (4.6.3 from kernel.org), same configuration file, same
>>> command
>>> line.
>>> Configuration file is generated from defconfig, and the resulting .config
>>> file
>>> is the same in both cases.
>>>
>>> If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as
>>> parameter to it,
>>> it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails.
>>>
>>> I am puzzled. Guess there must be something different, but I have no idea
>>> what it might be.
>>
>>
>> What is the output of
>>
>> echo -e __XTENSA_EB__ | xtensa-linux-gcc -E -
>>
>> on the failing system?
>>
> It is "1", but that let me pinpoint the problem.
>
> On the failing system, the version of echo executed by make does
> not understand the "-e" option. Thus, when running
> arch/xtensa/boot/Makefile,
> "echo -e __XTENSA_EB__" returns "-e __XTENSA_EB__", which doesn't compile,
> and BIG_ENDIAN ends up being 0. So the compiler is completely innocent.
>
> I found out the root source: SHELL is set the /bin/sh, which on the failing
> system points to /bin/dash (default in Ubuntu, or at least it used to be).
> dash apparently has a built-in version of echo which does not understand
> '-e'.
> Oh well.
Cool. OTOH I don't think that we need to -e to output __XTENSA_EB__.
Will send a patch for that.
--
Thanks.
-- Max
On Fri, Aug 16, 2013 at 09:26:51PM +0200, Sam Ravnborg wrote:
> On Fri, Aug 16, 2013 at 08:43:35AM -0700, Guenter Roeck wrote:
> > On 08/16/2013 02:45 AM, Max Filippov wrote:
> >>>> Guenter,
> >>>> can you share a complete build log with V=1?
> >>>>
> >>>
> >>> http://roeck-us.net/linux/logs/make.xtensa.log.bad
> >>> http://roeck-us.net/linux/logs/make.xtensa.log.ok
> >>>
> >>> Key difference: the failing command in the bad case is
> >>> xtensa-linux-objcopy -O elf32-xtensa-le
> >>> and in the good case
> >>> xtensa-linux-objcopy -O elf32-xtensa-be
> >>>
> >>> Same compiler (4.6.3 from kernel.org), same configuration file, same command
> >>> line.
> >>> Configuration file is generated from defconfig, and the resulting .config
> >>> file
> >>> is the same in both cases.
> >>>
> >>> If I execute make and expicitly set BIG_ENDIAN=1 on the failing system as
> >>> parameter to it,
> >>> it works fine. If I set BIG_ENDIAN=0 on the passing system, it fails.
> >>>
> >>> I am puzzled. Guess there must be something different, but I have no idea
> >>> what it might be.
> >>
> >> What is the output of
> >>
> >> echo -e __XTENSA_EB__ | xtensa-linux-gcc -E -
> >>
> >> on the failing system?
> >>
> > It is "1", but that let me pinpoint the problem.
> >
> > On the failing system, the version of echo executed by make does
> > not understand the "-e" option. Thus, when running arch/xtensa/boot/Makefile,
> > "echo -e __XTENSA_EB__" returns "-e __XTENSA_EB__", which doesn't compile,
> > and BIG_ENDIAN ends up being 0. So the compiler is completely innocent.
> >
> > I found out the root source: SHELL is set the /bin/sh, which on the failing
> > system points to /bin/dash (default in Ubuntu, or at least it used to be).
> > dash apparently has a built-in version of echo which does not understand '-e'.
>
> Could you try to replace "echo -e bla" with "printf "bla".
> Kbuild.include uses some similar tricks but here printf is used.
> Maybe this can be dash compatible then
>
"echo" would do perfectly fine in this case. Besides, there are more
"echo -e" in arch/xtensa/Makefile. Those only cause unpredictable build
results (because neither big endian not little endian is set because of it),
but no errors.
Problem is that "echo -e" is used elsewhere in various kernel makefiles,
not just for xtensa. Those don't cause odd errors like the one I observed,
but may result in unpredictable behavior. I am not sure if I should try
to fix that.
Maybe we should just put "don't try to compile the linux kernel with dash
as default shell" as a note somewhere.
Guenter
> >
> > I found out the root source: SHELL is set the /bin/sh, which on the failing
> > system points to /bin/dash (default in Ubuntu, or at least it used to be).
> > dash apparently has a built-in version of echo which does not understand
> > '-e'.
> > Oh well.
>
> Cool. OTOH I don't think that we need to -e to output __XTENSA_EB__.
> Will send a patch for that.
Could you please take a look at the other places that uses "echo -e".
At least one usage inarch/x86/Makefiel looks questionable.
grep did not turn up many uses.
Sam