[Suggestion] arc: compiler: bug: about an arc compiler's bug which is not in gcc main source code.

[Chen Gang]

Hello arc members:

It is arc compiler's bug, but can not report to gnu tool chain (it is
not integrated into gnu tool chain), so have to report it here (I find
this bug here, and I guess, some arc folks are here, too).


In "drivers/power/wm831x_power.c", all wm831x_bat_get_prop() calling
functions are inline, so wm831x_bat_get_prop() size is more than 256,
but it uses 1 byte to express related offset (".byte .L61-.L65 + 6").

If let some of wm831x_bat_get_prop() calling functions noinline, it can
pass compiling.

The related .s file is in attachment, and the related command and error
(for next-20130920 tree) is below:

/usr/local/bin/arc-elf32-gcc -Wp,-MD,drivers/power/.wm831x_power.o.d -nostdinc -isystem /usr/local/lib/gcc/arc-elf32/4.4.7/include -I/root/linux-next/arch/arc/include -Iarch/arc/include/generated -Iinclude -I/root/linux-next/arch/arc/include/uapi -Iarch/arc/include/generated/uapi -I/root/linux-next/include/uapi -Iinclude/generated/uapi -include /root/linux-next/include/linux/kconfig.h -include /root/linux-next/arch/arc/include/asm/current.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -mA7 -fno-common -pipe -fno-builtin -D__linux__ -fsection-anchors -mlock -mswape -mrtsc -fasynchronous-unwind-tables -mno-sdata -fcall-used-gp -mbig-endian -multcost=16 -fno-reorder-blocks -fno-ipa-cp-clone -Wframe-larger-than=1024 -fno-stack-protector -fomit-frame-pointer -g -femit-struct-debug-baseonly -fno-var-tracking -fno-inline-functions-cal
led-once
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -DDEBUG -DMODULE -mlong-calls -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(wm831x_power)" -D"KBUILD_MODNAME=KBUILD_STR(wm831x_power)" -c -o drivers/power/.tmp_wm831x_power.o drivers/power/wm831x_power.c
{standard input}: Assembler messages:
{standard input}:934: Error: value of 256 too large for field of 1 bytes at 1987


Welcome any suggestions or completions (e.g. which location and members
this bug should be reported to).

Thanks.
--
Chen Gang

[Chen Gang]

Oh, I forgot to supply the related arc cross-compiler's information:

[root@dhcp122 linux-next]# /usr/local/bin/arc-elf32-gcc -v
Using built-in specs.
Target: arc-elf32
Configured with: /mnt/sda11/src/toolchain_arc/unisrc/configure --target=arc-elf32 --with-cpu=arc700 --disable-werror --disable-multilib --with-pkgversion='ARCompact elf32 toolchain (built 20130922)' --with-bugurl=http://solvnet.synopsys.com --enable-fast-install=N/A --enable-languages=c,c++ --prefix=/usr/local --with-headers=/mnt/sda11/src/toolchain_arc/unisrc/newlib/libc/include
Thread model: single
gcc version 4.4.7 (ARCompact elf32 toolchain (built 20130922))

[root@dhcp122 linux-next]# /usr/local/bin/arc-elf32-as -v
GNU assembler version 2.19.50.ARC_4.4 (arc-elf32) using BFD version (ARCompact elf32 toolchain (built 20130922)) 2.19.50.ARC_4.4.20081103

[root@dhcp122 linux-next]# /usr/local/bin/arc-elf32-ld -v
GNU ld (ARCompact elf32 toolchain (built 20130922)) 2.19.50.ARC_4.4.20081103

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Vineet Gupta]

Hi Chen,

Thanks for the problem report. Please note that we have moved on to gcc 4.8 based
tool-chain so I would suggest you switch over to it too (4.4 support is really
phased out).

With current 4.8 tools, I don't see the error you report.

Please use the arc-4.8-dev branch of toolchain repo on github for building the
tools, assuming that is where you got the sources for 4.4 tools too.

Jeremy, Claudiu, Joern maintain the gcc and rest of GNU toolchain ports for ARC so
please add them to any future posting on toolchain issues.

Thx,
-Vineet

[Chen Gang]

On 09/23/2013 02:39 PM, Vineet Gupta wrote:
> Hi Chen,
>
> Thanks for the problem report. Please note that we have moved on to gcc 4.8 based
> tool-chain so I would suggest you switch over to it too (4.4 support is really
> phased out).
>
> With current 4.8 tools, I don't see the error you report.
>
> Please use the arc-4.8-dev branch of toolchain repo on github for building the
> tools, assuming that is where you got the sources for 4.4 tools too.
>

OK, thanks, I should try 4.8. :-)

> Jeremy, Claudiu, Joern maintain the gcc and rest of GNU toolchain ports for ARC so
> please add them to any future posting on toolchain issues.
>

Thank you very much for your information.

> Thx,
> -Vineet


Thanks.
--
Chen Gang

[Chen Gang]

On 09/23/2013 02:53 PM, Chen Gang wrote:
> On 09/23/2013 02:39 PM, Vineet Gupta wrote:
>> Hi Chen,
>>

...

>>
>> Jeremy, Claudiu, Joern maintain the gcc and rest of GNU toolchain ports for ARC so
>> please add them to any future posting on toolchain issues.
>>

Firstly, sorry for so late to continue arc. Now I use latest tool-chain
(content gcc-4.8.0) to compile kernel with allmodconfig, and find three
tool chain issues (2 for gcc, 1 for binutils).

And also excuse me, I am still not quite sure where I should sent these
information to, although you have mentioned some valuable information.

I just list the issue details below, if necessary, please provide more
details where these information should be sent to (e.g. bugzilla), and
I will/should follow and work with related tool chain guys. thanks.


-------------------------information begin----------------------------

Operation:

for Linux next-20130927 tree
make ARCH=arc CROSS_COMPILE=/usr/local/bin/arc-elf32- allmodconfig
make ARCH=arc CROSS_COMPILE=/usr/local/bin/arc-elf32-

Binutils (1 issue, ld and as information):

when calling panic(), printk(), or memset() with R_ARC_S21W_PCREL, it may be overflow (I guess it need be R_ARC_S25W_PCREL).

/usr/local/bin/arc-elf32-ld --build-id -X -o .tmp_vmlinux1 -T /android/public-kernel/linux-next/arch/arc/kernel/vmlinux.lds arch/arc/kernel/head.o init/built-in.o --start-group usr/built-in.o arch/arc/built-in.o arch/arc/boot/dts/built-in.o arch/arc/plat-arcfpga/built-in.o arch/arc/plat-tb10x/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a arch/arc/lib/lib.a /usr/local/lib/gcc/arc-elf32/4.8.0/libgcc.a lib/built-in.o arch/arc/lib/built-in.o /usr/local/lib/gcc/arc-elf32/4.8.0/libgcc.a drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o --end-group
/usr/local/bin/arc-elf32-ld: Error: Overflow detected in relocation value;
/usr/local/bin/arc-elf32-ld: Relocation value should be between 1048575 and -1048576 whereas it 2404264
/usr/local/bin/arc-elf32-ld: Global symbol: "panic".
/usr/local/bin/arc-elf32-ld:
Relocation type is:R_ARC_S21W_PCREL
FileName:arch/arc/built-in.o
Section Name:.text
Offset in Section:1716
/usr/local/bin/arc-elf32-ld: final link failed: Bad value
make: *** [vmlinux] Error 1

[root@gchenlinux binutils]# arc-elf32-ld -v
GNU ld (GNU Binutils) 2.23.2

[root@gchenlinux binutils]# arc-elf32-as -v
GNU assembler version 2.23.2 (arc-elf32) using BFD version (GNU Binutils) 2.23.2

GCC (2 issues, and gcc information):

CC drivers/rtc/systohc.o
drivers/rtc/systohc.c: In function 'rtc_set_ntp_time':
drivers/rtc/systohc.c:44:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:8315
}
^
0x939c94 arc_ifcvt
../../gcc/gcc/config/arc/arc.c:8315
0x93a394 arc_reorg
../../gcc/gcc/config/arc/arc.c:5985
0x7517d9 rest_of_handle_machine_reorg
../../gcc/gcc/reorg.c:3927
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [drivers/rtc/systohc.o] Error 1
make[1]: *** [drivers/rtc] Error 2
make: *** [drivers] Error 2


CC [M] drivers/target/target_core_pr.o
drivers/target/target_core_pr.c: In function 'target_scsi3_emulate_pr_in':
drivers/target/target_core_pr.c:4033:1: error: unrecognizable insn:
}
^
(insn 846 194 196 12 (set (reg:QI 1 r1)
(subreg:QI (mem/j/c:DI (plus:SI (reg/v/f:SI 2 r2 [orig:199 pr_reg ] [199])
(const_int 576 [0x240])) [0 pr_reg_50->pr_res_key+0 S8 A32]) 7)) drivers/target/target_core_pr.c:3677 -1
(nil))
drivers/target/target_core_pr.c:4033:1: internal compiler error: in extract_insn, at recog.c:2151
0x758fb5 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:109
0x758fe9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:117
0x726e83 extract_insn(rtx_def*)
../../gcc/gcc/recog.c:2151
0x726ef4 extract_insn_cached(rtx_def*)
../../gcc/gcc/recog.c:2054
0x5fe026 cleanup_subreg_operands(rtx_def*)
../../gcc/gcc/final.c:3305
0x750c2e reload(rtx_def*, int)
../../gcc/gcc/reload1.c:1240
0x68e703 do_reload
../../gcc/gcc/ira.c:4631
0x68e703 rest_of_handle_reload
../../gcc/gcc/ira.c:4731
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [drivers/target/target_core_pr.o] Error 1
make[1]: *** [drivers/target] Error 2
make: *** [drivers] Error 2


[root@gchenlinux linux-next]# /usr/local/bin/arc-elf32-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/arc-elf32-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/arc-elf32/4.8.0/lto-wrapper
Target: arc-elf32
Configured with: ../gcc/configure --without-header --disable-nls --enable-language=c --disable-threads --disable-shared --enable-werror=no target_configargs=enable_vtable_verify=yes --target=arc-elf32 --with-cpu=arc700 : (reconfigured) ../gcc/configure --disable-nls --enable-language=c --disable-threads --disable-shared --enable-werror=no target_configargs=enable_vtable_verify=yes --target=arc-elf32 --with-cpu=arc700 : (reconfigured) ../gcc/configure --without-header --disable-nls --enable-language=c --disable-threads --disable-shared --enable-werror=no target_configargs=enable_vtable_verify=yes --target=arc-elf32 --with-cpu=arc700 --disable-multilib --with-headers=../newlib/newlib/libc/include
Thread model: single
gcc version 4.8.0 (GCC)

-------------------------information end------------------------------

[Joern Rennecke]

On 23 October 2013 03:00, Chen Gang <gang...@asianux.com> wrote:

> Binutils (1 issue, ld and as information):
>
> when calling panic(), printk(), or memset() with R_ARC_S21W_PCREL, it may be overflow (I guess it need be R_ARC_S25W_PCREL).
>
> /usr/local/bin/arc-elf32-ld --build-id -X -o .tmp_vmlinux1 -T /android/public-kernel/linux-next/arch/arc/kernel/vmlinux.lds arch/arc/kernel/head.o init/built-in.o --start-group usr/built-in.o arch/arc/built-in.o arch/arc/boot/dts/built-in.o arch/arc/plat-arcfpga/built-in.o arch/arc/plat-tb10x/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a arch/arc/lib/lib.a /usr/local/lib/gcc/arc-elf32/4.8.0/libgcc.a lib/built-in.o arch/arc/lib/built-in.o /usr/local/lib/gcc/arc-elf32/4.8.0/libgcc.a drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o --end-group
> /usr/local/bin/arc-elf32-ld: Error: Overflow detected in relocation value;
> /usr/local/bin/arc-elf32-ld: Relocation value should be between 1048575 and -1048576 whereas it 2404264
> /usr/local/bin/arc-elf32-ld: Global symbol: "panic".
> /usr/local/bin/arc-elf32-ld:
> Relocation type is:R_ARC_S21W_PCREL
> FileName:arch/arc/built-in.o
> Section Name:.text
> Offset in Section:1716
> /usr/local/bin/arc-elf32-ld: final link failed: Bad value
> make: *** [vmlinux] Error 1

That just means that the image is too large to allow conditional
pc-relative calls (tail/sibcalls) or otherwise.

You can avoid generating them for functions with out a relevant
attribute with -mmedium-calls .

Can these issues be reproduced with the lastest gcc version? If so,
can you provide preprocessed source of the testcases and the compiler
flags to trigger the ICEs?

[Francois Bedard]

Hi Chen,

Our sources are on github at https://github.com/foss-for-synopsys-dwc-arc-processors and you can report problems by opening "Issues" with command lines and log outputs below against relevant toolchain component:

For GCC: https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues?state=open
For binutils: https://github.com/foss-for-synopsys-dwc-arc-processors/binutils/issues?page=1&state=open

Go ahead and officially file these and we'll take a look at them.

Thanks,

Francois

[Chen Gang]

On 10/23/2013 10:51 AM, Francois Bedard wrote:
> Our sources are on github at https://github.com/foss-for-synopsys-dwc-arc-processors and you can report problems by opening "Issues" with command lines and log outputs below against relevant toolchain component:
>
> For GCC: https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues?state=open
> For binutils: https://github.com/foss-for-synopsys-dwc-arc-processors/binutils/issues?page=1&state=open
>
> Go ahead and officially file these and we'll take a look at them.

I will/should go ahead, hope I can finish reporting them within this
week (2013-10-27)

[Chen Gang]

On 10/23/2013 10:48 AM, Joern Rennecke wrote:
> On 23 October 2013 03:00, Chen Gang <gang...@asianux.com> wrote:
>
>> Binutils (1 issue, ld and as information):
>>
>> when calling panic(), printk(), or memset() with R_ARC_S21W_PCREL, it may be overflow (I guess it need be R_ARC_S25W_PCREL).
>>
>> /usr/local/bin/arc-elf32-ld --build-id -X -o .tmp_vmlinux1 -T /android/public-kernel/linux-next/arch/arc/kernel/vmlinux.lds arch/arc/kernel/head.o init/built-in.o --start-group usr/built-in.o arch/arc/built-in.o arch/arc/boot/dts/built-in.o arch/arc/plat-arcfpga/built-in.o arch/arc/plat-tb10x/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a arch/arc/lib/lib.a /usr/local/lib/gcc/arc-elf32/4.8.0/libgcc.a lib/built-in.o arch/arc/lib/built-in.o /usr/local/lib/gcc/arc-elf32/4.8.0/libgcc.a drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o --end-group
>> /usr/local/bin/arc-elf32-ld: Error: Overflow detected in relocation value;
>> /usr/local/bin/arc-elf32-ld: Relocation value should be between 1048575 and -1048576 whereas it 2404264
>> /usr/local/bin/arc-elf32-ld: Global symbol: "panic".
>> /usr/local/bin/arc-elf32-ld:
>> Relocation type is:R_ARC_S21W_PCREL
>> FileName:arch/arc/built-in.o
>> Section Name:.text
>> Offset in Section:1716
>> /usr/local/bin/arc-elf32-ld: final link failed: Bad value
>> make: *** [vmlinux] Error 1
>
> That just means that the image is too large to allow conditional
> pc-relative calls (tail/sibcalls) or otherwise.
>
> You can avoid generating them for functions with out a relevant
> attribute with -mmedium-calls .
>

OK, thanks, I will/should try (it should be OK).

BTW: after pass this, kernel may pass the whole cross compiling with
allmodconfig (the other 2 gcc issues, can reconstruct source code to
bypass).

OK, thanks, I will/should try, hope I can finish within this month
(2013-10-31).

Thanks.
--
Chen Gang

[Chen Gang]

On 10/23/2013 11:10 AM, Chen Gang wrote:
> On 10/23/2013 10:48 AM, Joern Rennecke wrote:
>>
>> That just means that the image is too large to allow conditional
>> pc-relative calls (tail/sibcalls) or otherwise.
>>
>> You can avoid generating them for functions with out a relevant
>> attribute with -mmedium-calls .
>>

After try, it is OK (pass compiling), and I will continue the arc kernel
and try to finish allmodconfig cross compiling.

Thanks again.

> OK, thanks, I will/should try (it should be OK).
>
> BTW: after pass this, kernel may pass the whole cross compiling with
> allmodconfig (the other 2 gcc issues, can reconstruct source code to
> bypass).
>

[Chen Gang]

For some architectures, tool chain is not smart enough to recognize the
macro with multiple lines (e.g. arc tool chain), and for common ".S"
file, this kind of macro is also rarely used.

So expand the related contents of macro to let it pass compiling (can
use "arc-elf32-objdump -x" to know about it).

The related error (allmodconfig for arc):

LD init/built-in.o
kernel/built-in.o: In function `load_module_signing_keys':
kernel/modsign_pubkey.c:66: undefined reference to `modsign_certificate_list'
kernel/modsign_pubkey.c:71: undefined reference to `modsign_certificate_list_end'
kernel/modsign_pubkey.c:67: undefined reference to `modsign_certificate_list_end'

The related tool chain information:

[root@gchenlinux linux-next]# arc-elf32-as -v

GNU assembler version 2.23.2 (arc-elf32) using BFD version (GNU Binutils) 2.23.2

[root@gchenlinux linux-next]# arc-elf32-ld -v

GNU ld (GNU Binutils) 2.23.2

[root@gchenlinux linux-next]# arc-elf32-gcc -v
Using built-in specs.
COLLECT_GCC=arc-elf32-gcc

COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/arc-elf32/4.8.0/lto-wrapper
Target: arc-elf32
Configured with: ../gcc/configure --without-header --disable-nls --enable-language=c --disable-threads --disable-shared --enable-werror=no target_configargs=enable_vtable_verify=yes --target=arc-elf32 --with-cpu=arc700 : (reconfigured) ../gcc/configure --disable-nls --enable-language=c --disable-threads --disable-shared --enable-werror=no target_configargs=enable_vtable_verify=yes --target=arc-elf32 --with-cpu=arc700 : (reconfigured) ../gcc/configure --without-header --disable-nls --enable-language=c --disable-threads --disable-shared --enable-werror=no target_configargs=enable_vtable_verify=yes --target=arc-elf32 --with-cpu=arc700 --disable-multilib --with-headers=../newlib/newlib/libc/include
Thread model: single
gcc version 4.8.0 (GCC)

Signed-off-by: Chen Gang <gang...@asianux.com>
---
kernel/modsign_certificate.S | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/kernel/modsign_certificate.S b/kernel/modsign_certificate.S
index 4a9a86d..1967dcd 100644
--- a/kernel/modsign_certificate.S
+++ b/kernel/modsign_certificate.S
@@ -1,12 +1,10 @@
#include <linux/export.h>

-#define GLOBAL(name) \
- .globl VMLINUX_SYMBOL(name); \
- VMLINUX_SYMBOL(name):
-
.section ".init.data","aw"

-GLOBAL(modsign_certificate_list)
+ .globl VMLINUX_SYMBOL(modsign_certificate_list)
+VMLINUX_SYMBOL(modsign_certificate_list):
.incbin "signing_key.x509"
.incbin "extra_certificates"
-GLOBAL(modsign_certificate_list_end)
+ .globl VMLINUX_SYMBOL(modsign_certificate_list_end)
+VMLINUX_SYMBOL(modsign_certificate_list_end):
--
1.7.7.6

[Richard Weinberger]

On Thu, Oct 24, 2013 at 7:31 AM, Chen Gang <gang...@asianux.com> wrote:
> For some architectures, tool chain is not smart enough to recognize the
> macro with multiple lines (e.g. arc tool chain), and for common ".S"
> file, this kind of macro is also rarely used.

Does not "not smart enough" mean than the said toolchain is broken/buggy
or is the kernel using an unsupported notation?

--
Thanks,
//richard

[Chen Gang]

On 10/24/2013 02:03 PM, Richard Weinberger wrote:
> On Thu, Oct 24, 2013 at 7:31 AM, Chen Gang <gang...@asianux.com> wrote:
>> For some architectures, tool chain is not smart enough to recognize the
>> macro with multiple lines (e.g. arc tool chain), and for common ".S"
>> file, this kind of macro is also rarely used.
>
> Does not "not smart enough" mean than the said toolchain is broken/buggy
> or is the kernel using an unsupported notation?
>

Hmm... maybe my comments is not quite precise, what I want to say is:

- another architectures tool chain (e.g. arm-linux-gnueabi-) support it.
but our tool chain (arc-elf32-) will cause issue.

- in kernel source, excluding "arch/" sub directory, excep this file and one x86 drivers, no one use macro in this way, now.
and in "arch/arc/" sub-directory, no one use macro in this way, too.
the related find command: "find | grep "\.S$" | grep -v "/arch/" | grep -v "Documentation" | xargs grep define"

So at least, for kernel itself, better change the using way (only 2
areas use the macro, and the macro only contents 2 lines, so it is
acceptable enough to expand it).


Anyway, maybe it is also the tool chain's bug (so I include related arc
tool chain guys in this mail).


Thanks.

Chen Gang

[Richard Weinberger]

Am 24.10.2013 08:26, schrieb Chen Gang:
> On 10/24/2013 02:03 PM, Richard Weinberger wrote:
> Anyway, maybe it is also the tool chain's bug (so I include related arc
> tool chain guys in this mail).

That's exactly my point. Before you blindly patch the kernel just to make it
somehow build you need to find the root cause.
Do you even have an ARC board to test the kernel?

Thanks,
//richard

[Chen Gang]

On 10/24/2013 02:44 PM, Richard Weinberger wrote:
> Am 24.10.2013 08:26, schrieb Chen Gang:
>> On 10/24/2013 02:03 PM, Richard Weinberger wrote:
>> Anyway, maybe it is also the tool chain's bug (so I include related arc
>> tool chain guys in this mail).
>
> That's exactly my point. Before you blindly patch the kernel just to make it
> somehow build you need to find the root cause.
> Do you even have an ARC board to test the kernel?
>

Hmm... I don't think it is blindly, at least, we can not say: "if tool
chain has issues, we should not use it, if we have no related hard
wares, it is useless to compile them".

We are focus on the contribution, not on whether others have issues or
'qualifications', if we are sure this patch should be useful, we need go
ahead.

For normal members, it is not quite important, but for managerial
members or a company, of cause, they will/should understand these rules.


> Thanks,
> //richard
>
>
>

Thanks.
--
Chen Gang

[Josh Boyer]

Is this only an issue with using multi-line macro definitions in .S
files? The practice of using multi-line macro definitions isn't rare.
Look at e.g. include/linux/module.h, and a number of other header
files.

This seems like a toolchain bug that should be fixable if it works for
other architectures.

josh

[Vineet Gupta]

+CC linux-arch

On 10/24/2013 11:33 AM, Richard Weinberger wrote:
> On Thu, Oct 24, 2013 at 7:31 AM, Chen Gang <gang...@asianux.com> wrote:
>> > For some architectures, tool chain is not smart enough to recognize the
>> > macro with multiple lines (e.g. arc tool chain), and for common ".S"
>> > file, this kind of macro is also rarely used.
> Does not "not smart enough" mean than the said toolchain is broken/buggy
> or is the kernel using an unsupported notation?
>

IMHO this is not broken - rather the code is not fully portable - given that gas
ports of arches have differnet notions of what to treat as comment and what newline.

Looking as binutils/gas/config, I can see that avr, cris,...are likely broken in
the same way as ARC is.

Historically ARC has had ';' as comment char, which Joern relatively recently
augmented to have '#' as well. However there's legacy codebase which relies on ';'
being a comment and we can't change that fact.

So can we introduce an ARCH over-ridable newline annotation in linkage.h and other
places after auditing. Since asm/linkage.h preempts linux/linkage.h by way of
#include it shd be pretty strightforward.

Something like below. I can send the formal patch if people think the approach is OK.


----------------->
diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index d3e8ad23a8e0..4188c632f2b8 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -6,6 +6,10 @@
#include <linux/export.h>
#include <asm/linkage.h>

+#ifndef __ARCH_NL
+#define __ARCH_NL
+#endif
+
#ifdef __cplusplus
#define CPP_ASMLINKAGE extern "C"
#else
@@ -75,7 +79,7 @@

#ifndef ENTRY
#define ENTRY(name) \
- .globl name; \
+ .globl name; __ARCH_NL \
ALIGN; \
name:
#endif
@@ -83,7 +87,7 @@

#ifndef WEAK
#define WEAK(name) \
- .weak name; \
+ .weak name; __ARCH_NL \
name:
#endif

[Geert Uytterhoeven]

On Thu, Oct 24, 2013 at 7:28 PM, Vineet Gupta <vine...@gmail.com> wrote:
> +CC linux-arch
>
> On 10/24/2013 11:33 AM, Richard Weinberger wrote:
>> On Thu, Oct 24, 2013 at 7:31 AM, Chen Gang <gang...@asianux.com> wrote:
>>> > For some architectures, tool chain is not smart enough to recognize the
>>> > macro with multiple lines (e.g. arc tool chain), and for common ".S"
>>> > file, this kind of macro is also rarely used.
>> Does not "not smart enough" mean than the said toolchain is broken/buggy
>> or is the kernel using an unsupported notation?
>>
>
> IMHO this is not broken - rather the code is not fully portable - given that gas
> ports of arches have differnet notions of what to treat as comment and what newline.
>
> Looking as binutils/gas/config, I can see that avr, cris,...are likely broken in
> the same way as ARC is.
>
> Historically ARC has had ';' as comment char, which Joern relatively recently
> augmented to have '#' as well. However there's legacy codebase which relies on ';'
> being a comment and we can't change that fact.
>
> So can we introduce an ARCH over-ridable newline annotation in linkage.h and other
> places after auditing. Since asm/linkage.h preempts linux/linkage.h by way of
> #include it shd be pretty strightforward.
>
> Something like below. I can send the formal patch if people think the approach is OK.

By what are you gonna override __ARCH_NL on ARC?
I'm afraid cpp will still turn it into a single line.

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

[Vineet Gupta]

On 10/25/2013 01:11 AM, Geert Uytterhoeven wrote:
> On Thu, Oct 24, 2013 at 7:28 PM, Vineet Gupta <vine...@gmail.com> wrote:
>> > +CC linux-arch
>> >
>> > On 10/24/2013 11:33 AM, Richard Weinberger wrote:
>>> >> On Thu, Oct 24, 2013 at 7:31 AM, Chen Gang <gang...@asianux.com> wrote:
>>>>> >>> > For some architectures, tool chain is not smart enough to recognize the
>>>>> >>> > macro with multiple lines (e.g. arc tool chain), and for common ".S"
>>>>> >>> > file, this kind of macro is also rarely used.
>>> >> Does not "not smart enough" mean than the said toolchain is broken/buggy
>>> >> or is the kernel using an unsupported notation?
>>> >>
>> >
>> > IMHO this is not broken - rather the code is not fully portable - given that gas
>> > ports of arches have differnet notions of what to treat as comment and what newline.
>> >
>> > Looking as binutils/gas/config, I can see that avr, cris,...are likely broken in
>> > the same way as ARC is.
>> >
>> > Historically ARC has had ';' as comment char, which Joern relatively recently
>> > augmented to have '#' as well. However there's legacy codebase which relies on ';'
>> > being a comment and we can't change that fact.
>> >
>> > So can we introduce an ARCH over-ridable newline annotation in linkage.h and other
>> > places after auditing. Since asm/linkage.h preempts linux/linkage.h by way of
>> > #include it shd be pretty strightforward.
>> >
>> > Something like below. I can send the formal patch if people think the approach is OK.
> By what are you gonna override __ARCH_NL on ARC?
> I'm afraid cpp will still turn it into a single line.
>

Eh ! My untested patch was broken but not because of what you mentioned.

For ARC, the ; negating the newline annotation. So the following works (backquote
is new line for ARC)

diff --git a/arch/arc/include/asm/linkage.h b/arch/arc/include/asm/linkage.h
index 0283e9e44e0d..b3eea2999322 100644
--- a/arch/arc/include/asm/linkage.h
+++ b/arch/arc/include/asm/linkage.h
@@ -9,6 +9,8 @@
#ifndef __ASM_LINKAGE_H
#define __ASM_LINKAGE_H

+#define __ARCH_NL `
+
#ifdef __ASSEMBLY__


diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index d3e8ad23a8e0..969e70ad231a 100644

--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -6,6 +6,10 @@
#include <linux/export.h>
#include <asm/linkage.h>

+#ifndef __ARCH_NL
+#define __ARCH_NL ;
+#endif
+
#ifdef __cplusplus
#define CPP_ASMLINKAGE extern "C"
#else
@@ -75,7 +79,7 @@

#ifndef ENTRY
#define ENTRY(name) \
- .globl name; \
+ .globl name __ARCH_NL \
ALIGN; \
name:
#endif

[Chen Gang]

Yes, excluding "arch/*", for all ".S" files, except x86 driver and this
file, no others use multi-line macro definition, and "arch/arc" don't
use mulit-line macro definitions, either.

The related search command is:

"find | grep -i "\.S$" | grep -v "/arch/" | grep -v "Documentation" | xargs grep define".

Hmm... at least, in our case, we need not use the multi-line macro
definition, if expand it, the total lines will be shrunk, that will
be more clearer and simpler to source code readers and writers.

> This seems like a toolchain bug that should be fixable if it works for
> other architectures.
>

Hmm... at least, we are sure the toolchain is not quite smart enough
(but we can not say it must be a bug).


So for me, I recommend to apply this patch (maybe the patch comment
need improvement). It is quite valuable to continue discussing about
it, but it is not related with whether applying this patch or not.

> josh
>
>

Thanks.
--
Chen Gang

[Chen Gang]

Do we also need consider about "ALIGN;"?

> name:
> #endif
>

For next-20130927 tree, do we also need consider about WEAK, ENDPROC?


I am not quite sure about it, but I will try. Now, I am just analyzing
another issue -- maybe the last issue for allmodconfig under arc, which
may be related with this patch, the errors are:

1 Building modules, stage 2.
2 MODPOST 2994 modules
3 ERROR: "__st_r13_to_r20" [sound/usb/snd-usbmidi-lib.ko] undefined!
4 ERROR: "__ld_r13_to_r15" [sound/usb/snd-usbmidi-lib.ko] undefined!
5 ERROR: "__st_r13_to_r18" [sound/usb/snd-usbmidi-lib.ko] undefined!
6 ERROR: "__ld_r13_to_r14_ret" [sound/usb/snd-usbmidi-lib.ko] undefined!
7 ERROR: "__ld_r13_to_r22" [sound/usb/snd-usbmidi-lib.ko] undefined!
8 ERROR: "__ld_r13_to_r15_ret" [sound/usb/snd-usbmidi-lib.ko] undefined!
9 ERROR: "__ld_r13_to_r16" [sound/usb/snd-usbmidi-lib.ko] undefined!
10 ERROR: "__ld_r13_to_r18_ret" [sound/usb/snd-usbmidi-lib.ko] undefined!
11 ERROR: "__ld_r13_to_r24_ret" [sound/usb/snd-usbmidi-lib.ko] undefined!
...
...

28095 ERROR: "__st_r13_to_r17" [arch/arc/oprofile/oprofile.ko] undefined!
28096 ERROR: "__st_r13_to_r22" [arch/arc/oprofile/oprofile.ko] undefined!
28097 ERROR: "__ld_r13_to_r19_ret" [Documentation/filesystems/configfs/configfs_example_macros.ko] undefined!
28098 ERROR: "__st_r13_to_r19" [Documentation/filesystems/configfs/configfs_example_macros.ko] undefined!
28099 ERROR: "__ld_r13_to_r14_ret" [Documentation/filesystems/configfs/configfs_example_macros.ko] undefined!
28100 ERROR: "__ld_r13_to_r19_ret" [Documentation/filesystems/configfs/configfs_example_explicit.ko] undefined!
28101 ERROR: "__st_r13_to_r19" [Documentation/filesystems/configfs/configfs_example_explicit.ko] undefined!
28102 ERROR: "__ld_r13_to_r14_ret" [Documentation/filesystems/configfs/configfs_example_explicit.ko] undefined!
28103 ERROR: "__ld_r13_to_r14_ret" [Documentation/connector/cn_test.ko] undefined!
28104 make[1]: *** [__modpost] Error 1
28105 make: *** [modules] Error 2


Thanks.
--
Chen Gang

[Chen Gang F T]

Oh, sorry, what my written is not quite precise, and my real meaning is:
"no others *intend* to use multi-line macro definition in *.S".

[Vineet Gupta]

Right - as I said already, above was not a formal patch but a RFC whether we are
on right track. The proper fix will have to audit all such places.

>> name:
>> #endif
>>
>
> For next-20130927 tree, do we also need consider about WEAK, ENDPROC?

Indeed.

> I am not quite sure about it, but I will try.

So you volunteer to send out a patch base don __ARCH_NL I proposed above ?

> Now, I am just analyzing
> another issue -- maybe the last issue for allmodconfig under arc, which
> may be related with this patch, the errors are:
>
> 1 Building modules, stage 2.
> 2 MODPOST 2994 modules
> 3 ERROR: "__st_r13_to_r20" [sound/usb/snd-usbmidi-lib.ko] undefined!

Yes we know about this already. This is to do with libgcc linkage. The fix is non
trivial - I'll get back to you on this. For now disable CONFIG_CC_OPTIMIZE_FOR_SIZE.

-Vineet

[Chen Gang]

OK, I will/should try.

Hmm... I am 'almost' a volunteer: my company support what I have done
for Public Open Source, they treat it as important thing.

Now you are mainly focusing on arc, and I want/try to focus on kernel
wide. This patch belongs to kernel wide, and at least now, nobody
rejects me for it, so I will/should try.

>> Now, I am just analyzing
>> another issue -- maybe the last issue for allmodconfig under arc, which
>> may be related with this patch, the errors are:
>>
>> 1 Building modules, stage 2.
>> 2 MODPOST 2994 modules
>> 3 ERROR: "__st_r13_to_r20" [sound/usb/snd-usbmidi-lib.ko] undefined!
>
> Yes we know about this already. This is to do with libgcc linkage. The fix is non
> trivial - I'll get back to you on this. For now disable CONFIG_CC_OPTIMIZE_FOR_SIZE.
>

OK, thank you for your valuable information in time, at least, it saves
my time resources, after pass this issue, hope our arc can pass
allmodconfig.

:-)

> -Vineet
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in

> the body of a message to majo...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

Thanks.
--
Chen Gang

--

Chen Gang

[Chen Gang]

In "include/asm-generic/vmlinux.lds.h", I guess "*(...)" also can
express an individual line, is it generic enough to arc, too?


Thanks.

>> -Vineet
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
>> the body of a message to majo...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> Thanks.
>


--
Chen Gang
--

[Chen Gang]

If a macro is only used within 2 times, and also its contents are
within 2 lines, recommend to expand it to shrink code line.

For our case, the macro is not portable either: some architectures'
assembler may use another character to mark newline in a macro (e.g.
'`' for arc), which will cause issue (e.g. arc with allmodconfig):

LD init/built-in.o
kernel/built-in.o: In function `load_module_signing_keys':
kernel/modsign_pubkey.c:66: undefined reference to `modsign_certificate_list'
kernel/modsign_pubkey.c:71: undefined reference to `modsign_certificate_list_end'
kernel/modsign_pubkey.c:67: undefined reference to `modsign_certificate_list_end'

If still want to use macro and let it portable enough, it will need
additional line -- include additional header file (e.g "#include
<linux/linkage.h>", although it also need be fixed).

[Chen Gang]

If a macro is only used within 2 times, and also its contents are
within 2 lines, recommend to expand it to shrink code line.

For our case, the macro is not portable either: some architectures'
assembler may use another character to mark newline in a macro (e.g.

'`' for arc), which will cause issue.

If still want to use macro and let it portable enough, it will also
need include additional header file (e.g "#include <linux/linkage.h>",

although it also need be fixed).


Signed-off-by: Chen Gang <gang...@asianux.com>
---

kernel/system_certificates.S | 10 ++++------

1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/kernel/system_certificates.S b/kernel/system_certificates.S
index 552d47b..4aef390 100644
--- a/kernel/system_certificates.S
+++ b/kernel/system_certificates.S

@@ -1,12 +1,10 @@
#include <linux/export.h>

#include <linux/init.h>

-#define GLOBAL(name) \
- .globl VMLINUX_SYMBOL(name); \
- VMLINUX_SYMBOL(name):
-

__INITRODATA

-GLOBAL(system_certificate_list)
+ .globl VMLINUX_SYMBOL(system_certificate_list)
+VMLINUX_SYMBOL(system_certificate_list):
.incbin "kernel/x509_certificate_list"
-GLOBAL(system_certificate_list_end)
+ .globl VMLINUX_SYMBOL(system_certificate_list_end)
+VMLINUX_SYMBOL(system_certificate_list_end):

[Chen Gang]

On 10/23/2013 11:12 AM, Chen Gang wrote:
> On 10/23/2013 10:51 AM, Francois Bedard wrote:
>> Our sources are on github at https://github.com/foss-for-synopsys-dwc-arc-processors and you can report problems by opening "Issues" with command lines and log outputs below against relevant toolchain component:
>>
>> For GCC: https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues?state=open
>> For binutils: https://github.com/foss-for-synopsys-dwc-arc-processors/binutils/issues?page=1&state=open
>>
>> Go ahead and officially file these and we'll take a look at them.
>

Hello Francois, I marked them at 2013-10-26 night (China time).

for gcc (3 issues, but #28 duplicates with #26):

https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues/26
https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues/27
https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues/28

for binutils (1 issue):

https://github.com/foss-for-synopsys-dwc-arc-processors/binutils/issues/21


Hello Joern, for current shrinking status:

for gcc issue #26, (#28 is its duplication):

issue command: arc-elf32-gcc -Os -fno-reorder-blocks -c systohc.i
source code: systohc.i contents 41 lines (past it on website).
whether GNU: only for arc, gnu no issue: gnu gcc-4.8/4.9 are OK.

for gcc issue #27:

issue command: arc-elf32-gcc -Os -c target_core_pr.i
status: just shrinking code.
will/should be finish within 2013-10-31.
welcome any suggestions or completions.

for binutils issue #21:

it seems simple enough, if still need shrinking, please let me know.


It seems no response, and I am a newbie about the website, need I do
something more for them? (e.g. cc to some members, although I don't
know how to cc).

[Chen Gang]

On 10/30/2013 09:43 AM, Chen Gang wrote:
> On 10/23/2013 11:12 AM, Chen Gang wrote:
>> On 10/23/2013 10:51 AM, Francois Bedard wrote:
>>> Our sources are on github at https://github.com/foss-for-synopsys-dwc-arc-processors and you can report problems by opening "Issues" with command lines and log outputs below against relevant toolchain component:
>>>
>>> For GCC: https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues?state=open
>>> For binutils: https://github.com/foss-for-synopsys-dwc-arc-processors/binutils/issues?page=1&state=open
>>>
>>> Go ahead and officially file these and we'll take a look at them.
>>
>
> Hello Francois, I marked them at 2013-10-26 night (China time).
>
> for gcc (3 issues, but #28 duplicates with #26):
>
> https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues/26
> https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues/27
> https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues/28
>
> for binutils (1 issue):
>
> https://github.com/foss-for-synopsys-dwc-arc-processors/binutils/issues/21
>
>
> Hello Joern, for current shrinking status:
>
> for gcc issue #26, (#28 is its duplication):
>
> issue command: arc-elf32-gcc -Os -fno-reorder-blocks -c systohc.i
> source code: systohc.i contents 41 lines (past it on website).
> whether GNU: only for arc, gnu no issue: gnu gcc-4.8/4.9 are OK.
>
> for gcc issue #27:
>
> issue command: arc-elf32-gcc -Os -c target_core_pr.i
> status: just shrinking code.
> will/should be finish within 2013-10-31.
> welcome any suggestions or completions.
>

For gnu gcc 4.8/4.9, it is OK (not cause issue). The target_core_pr.i is
still large, I will try to let is smaller and then upload to the website
tomorrow.

Welcome any suggestions or completions (especially for shrinking size,
or only generate related insn tree is enough?).

Thank.

[David Howells]

Chen Gang <gang...@asianux.com> wrote:

> If a macro is only used within 2 times, and also its contents are
> within 2 lines, recommend to expand it to shrink code line.
>
> For our case, the macro is not portable either: some architectures'
> assembler may use another character to mark newline in a macro (e.g.
> '`' for arc), which will cause issue.
>
> If still want to use macro and let it portable enough, it will also
> need include additional header file (e.g "#include <linux/linkage.h>",
> although it also need be fixed).

Fine by me.

Applied.

[Chen Gang]

On 10/30/2013 08:57 PM, David Howells wrote:
> Chen Gang <gang...@asianux.com> wrote:
>
>> If a macro is only used within 2 times, and also its contents are
>> within 2 lines, recommend to expand it to shrink code line.
>>
>> For our case, the macro is not portable either: some architectures'
>> assembler may use another character to mark newline in a macro (e.g.
>> '`' for arc), which will cause issue.
>>
>> If still want to use macro and let it portable enough, it will also
>> need include additional header file (e.g "#include <linux/linkage.h>",
>> although it also need be fixed).
>
> Fine by me.
>
> Applied.
>
>

Thanks.
--
Chen Gang

[Vineet Gupta]

Hi Chen,

Many thanks for all your efforts so far.

Most of your patches have already been folded into ARC for 3.13. I will send out
the patches for some of the cross-arch changes in next development cycle as
currently I need to finish up a few things for upcoming merge window.

We are actively working on toolchain issues and hopefully the fixes will make it
into next formal release of tools. Please check back in few weeks.

Thanks,
-Vineet

[Chen Gang]

On 10/31/2013 03:48 PM, Vineet Gupta wrote:
> Hi Chen,

>
> Many thanks for all your efforts so far.
>

Since I need provide contribution to Public Open Source, so what I have
done is what I should do. :-)

In fact, I really need improve myself: e.g. how to make negative effect
lowest (e.g. how to let more members pleased with what I have done), how
to improve efficiency (make my waste mail lower) ...

> Most of your patches have already been folded into ARC for 3.13. I will send out
> the patches for some of the cross-arch changes in next development cycle as
> currently I need to finish up a few things for upcoming merge window.
>

OK, thanks.

> We are actively working on toolchain issues and hopefully the fixes will make it
> into next formal release of tools. Please check back in few weeks.
>

OK, I will/should focus.

And for gcc issue #27, I shrank the demo source file is about 1K lines
(shrank from 50K lines to 1K lines), although it is still a big file
which can be shrunk more.

And excuse me, I don't know how to past this file on this website, so I
load it as attachment, please check.


Thanks.
--
Chen Gang