'COUNTER' and other same kind macros are too common to use, and easy to
get conflict with other modules. So add prefix for them.
The related warning (allmodconfig with score):
CC [M] drivers/md/raid1.o
In file included from drivers/md/raid1.c:42:0:
drivers/md/bitmap.h:93:0: warning: "COUNTER" redefined
#define COUNTER(x) (((bitmap_counter_t) x) & COUNTER_MAX)
^
In file included from ./arch/score/include/asm/ptrace.h:4:0,
from include/linux/sched.h:31,
from include/linux/blkdev.h:4,
from drivers/md/raid1.c:36:
./arch/score/include/uapi/asm/ptrace.h:13:0: note: this is the location of the previous definition
#define COUNTER 38
Signed-off-by: Chen Gang <[email protected]>
---
arch/score/include/uapi/asm/ptrace.h | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/score/include/uapi/asm/ptrace.h b/arch/score/include/uapi/asm/ptrace.h
index f59771a..7a0ead9 100644
--- a/arch/score/include/uapi/asm/ptrace.h
+++ b/arch/score/include/uapi/asm/ptrace.h
@@ -4,16 +4,16 @@
#define PTRACE_GETREGS 12
#define PTRACE_SETREGS 13
-#define PC 32
-#define CONDITION 33
-#define ECR 34
-#define EMA 35
-#define CEH 36
-#define CEL 37
-#define COUNTER 38
-#define LDCR 39
-#define STCR 40
-#define PSR 41
+#define SCORE_PC 32
+#define SCORE_CONDITION 33
+#define SCORE_ECR 34
+#define SCORE_EMA 35
+#define SCORE_CEH 36
+#define SOCRE_CEL 37
+#define SCORE_COUNTER 38
+#define SCORE_LDCR 39
+#define SCORE_STCR 40
+#define SCORE_PSR 41
#define SINGLESTEP16_INSN 0x7006
#define SINGLESTEP32_INSN 0x840C8000
--
1.9.2.459.g68773ac
On 06/21/2014 09:48 PM, Chen Gang wrote:
> 'COUNTER' and other same kind macros are too common to use, and easy to
> get conflict with other modules. So add prefix for them.
>
> The related warning (allmodconfig with score):
>
> CC [M] drivers/md/raid1.o
> In file included from drivers/md/raid1.c:42:0:
> drivers/md/bitmap.h:93:0: warning: "COUNTER" redefined
> #define COUNTER(x) (((bitmap_counter_t) x) & COUNTER_MAX)
> ^
> In file included from ./arch/score/include/asm/ptrace.h:4:0,
> from include/linux/sched.h:31,
> from include/linux/blkdev.h:4,
> from drivers/md/raid1.c:36:
> ./arch/score/include/uapi/asm/ptrace.h:13:0: note: this is the location of the previous definition
> #define COUNTER 38
>
>
> Signed-off-by: Chen Gang <[email protected]>
Any idea where to find a cross-compile toolchain for this architecture ?
Thanks,
Guenter
On 06/22/2014 01:16 PM, Guenter Roeck wrote:
> On 06/21/2014 09:48 PM, Chen Gang wrote:
>> 'COUNTER' and other same kind macros are too common to use, and easy to
>> get conflict with other modules. So add prefix for them.
>>
>> The related warning (allmodconfig with score):
>>
>> CC [M] drivers/md/raid1.o
>> In file included from drivers/md/raid1.c:42:0:
>> drivers/md/bitmap.h:93:0: warning: "COUNTER" redefined
>> #define COUNTER(x) (((bitmap_counter_t) x) & COUNTER_MAX)
>> ^
>> In file included from ./arch/score/include/asm/ptrace.h:4:0,
>> from include/linux/sched.h:31,
>> from include/linux/blkdev.h:4,
>> from drivers/md/raid1.c:36:
>> ./arch/score/include/uapi/asm/ptrace.h:13:0: note: this is the
>> location of the previous definition
>> #define COUNTER 38
>>
>>
>> Signed-off-by: Chen Gang <[email protected]>
>
> Any idea where to find a cross-compile toolchain for this architecture ?
>
I use latest source code of gcc and binutils with git.
related source code:
git://sourceware.org/git/binutils-gdb.git
git://gcc.gnu.org/git/gcc.git
Issues:
For binutils, have to use the latest one (I have fixed one segment
fault issue of gas for score, and integrated into gas main line by
maintainer in Jun 13, 2014).
For gcc (after binutils has installed), when building glibc, may need
modify the absolute path for score-elf-gas, score-elf-ld ... in
related auto-generated file.
Under ubuntu (but under fedora, it is OK), may need export
LD_LIBRARY_PATH=/usr/local/lib for searching libmpfr.so.
My current binary informations:
root@gchen:/upstream/toolchain/binutils-gdb# /usr/local/bin/score-elf-ld -v
GNU ld (GNU Binutils) 2.24.51.20140609
root@gchen:/upstream/toolchain/binutils-gdb# /usr/local/bin/score-elf-as -v
GNU assembler version 2.24.51 (score-elf) using BFD version (GNU Binutils) 2.24.51.20140609
root@gchen:/upstream/toolchain/binutils-gdb# /usr/local/bin/score-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/score-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/score-elf/4.10.0/lto-wrapper
Target: score-elf
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=score-elf --enable-obsolete
Thread model: single
gcc version 4.10.0 20140530 (experimental) (GCC)
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
Hi Chen,
Do you find other modules except device modules cause issues of compiling?
The applications of Score are limited. Acutally, some errors never occur
in the limited applications, for example, the conbination consists of
Score and the timer of SuperH. I'm not sure we should handle this kind
of error.
If the rule is that we should make sure "all" modules can be compiled
with Score, we will do it.
However, we still thanks for your check.
Best,
Lennox
2014-06-22 12:48 GMT+08:00 Chen Gang <[email protected]>:
> 'COUNTER' and other same kind macros are too common to use, and easy to
> get conflict with other modules. So add prefix for them.
>
> The related warning (allmodconfig with score):
>
> CC [M] drivers/md/raid1.o
> In file included from drivers/md/raid1.c:42:0:
> drivers/md/bitmap.h:93:0: warning: "COUNTER" redefined
> #define COUNTER(x) (((bitmap_counter_t) x) & COUNTER_MAX)
> ^
> In file included from ./arch/score/include/asm/ptrace.h:4:0,
> from include/linux/sched.h:31,
> from include/linux/blkdev.h:4,
> from drivers/md/raid1.c:36:
> ./arch/score/include/uapi/asm/ptrace.h:13:0: note: this is the location of the previous definition
> #define COUNTER 38
>
>
> Signed-off-by: Chen Gang <[email protected]>
> ---
> arch/score/include/uapi/asm/ptrace.h | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/score/include/uapi/asm/ptrace.h b/arch/score/include/uapi/asm/ptrace.h
> index f59771a..7a0ead9 100644
> --- a/arch/score/include/uapi/asm/ptrace.h
> +++ b/arch/score/include/uapi/asm/ptrace.h
> @@ -4,16 +4,16 @@
> #define PTRACE_GETREGS 12
> #define PTRACE_SETREGS 13
>
> -#define PC 32
> -#define CONDITION 33
> -#define ECR 34
> -#define EMA 35
> -#define CEH 36
> -#define CEL 37
> -#define COUNTER 38
> -#define LDCR 39
> -#define STCR 40
> -#define PSR 41
> +#define SCORE_PC 32
> +#define SCORE_CONDITION 33
> +#define SCORE_ECR 34
> +#define SCORE_EMA 35
> +#define SCORE_CEH 36
> +#define SOCRE_CEL 37
> +#define SCORE_COUNTER 38
> +#define SCORE_LDCR 39
> +#define SCORE_STCR 40
> +#define SCORE_PSR 41
>
> #define SINGLESTEP16_INSN 0x7006
> #define SINGLESTEP32_INSN 0x840C8000
> --
> 1.9.2.459.g68773ac
On 06/21/2014 10:33 PM, Chen Gang wrote:
[ ... ]
>> Any idea where to find a cross-compile toolchain for this architecture ?
>>
>
> I use latest source code of gcc and binutils with git.
>
> related source code:
>
> git://sourceware.org/git/binutils-gdb.git
> git://gcc.gnu.org/git/gcc.git
>
> Issues:
>
> For binutils, have to use the latest one (I have fixed one segment
> fault issue of gas for score, and integrated into gas main line by
> maintainer in Jun 13, 2014).
>
> For gcc (after binutils has installed), when building glibc, may need
> modify the absolute path for score-elf-gas, score-elf-ld ... in
> related auto-generated file.
>
> Under ubuntu (but under fedora, it is OK), may need export
> LD_LIBRARY_PATH=/usr/local/lib for searching libmpfr.so.
>
> My current binary informations:
>
> root@gchen:/upstream/toolchain/binutils-gdb# /usr/local/bin/score-elf-ld -v
> GNU ld (GNU Binutils) 2.24.51.20140609
> root@gchen:/upstream/toolchain/binutils-gdb# /usr/local/bin/score-elf-as -v
> GNU assembler version 2.24.51 (score-elf) using BFD version (GNU Binutils) 2.24.51.20140609
> root@gchen:/upstream/toolchain/binutils-gdb# /usr/local/bin/score-elf-gcc -v
> Using built-in specs.
> COLLECT_GCC=/usr/local/bin/score-elf-gcc
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/score-elf/4.10.0/lto-wrapper
> Target: score-elf
> 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=score-elf --enable-obsolete
> Thread model: single
> gcc version 4.10.0 20140530 (experimental) (GCC)
>
I did that, and managed to build gcc.
However, when trying to compile score defconfig, I get internal compiler errors in cc1
when compiling drivers/tty/tty_mutex.o and block/elevator.o.
CC block/elevator.o
score-elf-gcc: internal compiler error: Segmentation fault (program cc1)
0x40c073 execute
../../gcc/gcc/gcc.c:2848
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[1]: *** [block/elevator.o] Error 4
make: *** [block/elevator.o] Error 2
Do you see that as well ?
This is with
GNU assembler version 2.24.51 (score-elf) using BFD version (GNU Binutils) 2.24.51.20140622
and gcc configured with:
Configured with: ../gcc/configure --prefix=/opt/kernel/score --program-prefix=score-elf- \
--target=score-elf --without-header --disable-nls --enable-languages=c --disable-threads \
--disable-shared --enable-werror=no target_configargs=enable_vtable_verify=yes \
--enable-obsolete --disable-libssp --disable-libquadmath
Tip of gcc source is commit d8686b0aa945a, tip of binutils source is commit d17c74c1d41.
Your assembler fix is included in this version of binutils.
Thanks,
Guenter
On 06/22/2014 07:53 AM, Guenter Roeck wrote:
> On 06/21/2014 10:33 PM, Chen Gang wrote:
>
> [ ... ]
>
>>> Any idea where to find a cross-compile toolchain for this architecture ?
>>>
>>
>> I use latest source code of gcc and binutils with git.
>>
>> related source code:
>>
>> git://sourceware.org/git/binutils-gdb.git
>> git://gcc.gnu.org/git/gcc.git
>>
>> Issues:
>>
>> For binutils, have to use the latest one (I have fixed one segment
>> fault issue of gas for score, and integrated into gas main line by
>> maintainer in Jun 13, 2014).
>>
>> For gcc (after binutils has installed), when building glibc, may need
>> modify the absolute path for score-elf-gas, score-elf-ld ... in
>> related auto-generated file.
>>
>> Under ubuntu (but under fedora, it is OK), may need export
>> LD_LIBRARY_PATH=/usr/local/lib for searching libmpfr.so.
>>
>> My current binary informations:
>>
>> root@gchen:/upstream/toolchain/binutils-gdb# /usr/local/bin/score-elf-ld -v
>> GNU ld (GNU Binutils) 2.24.51.20140609
>> root@gchen:/upstream/toolchain/binutils-gdb# /usr/local/bin/score-elf-as -v
>> GNU assembler version 2.24.51 (score-elf) using BFD version (GNU Binutils) 2.24.51.20140609
>> root@gchen:/upstream/toolchain/binutils-gdb# /usr/local/bin/score-elf-gcc -v
>> Using built-in specs.
>> COLLECT_GCC=/usr/local/bin/score-elf-gcc
>> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/score-elf/4.10.0/lto-wrapper
>> Target: score-elf
>> 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=score-elf --enable-obsolete
>> Thread model: single
>> gcc version 4.10.0 20140530 (experimental) (GCC)
>>
>
> I did that, and managed to build gcc.
>
> However, when trying to compile score defconfig, I get internal compiler errors in cc1
> when compiling drivers/tty/tty_mutex.o and block/elevator.o.
>
> CC block/elevator.o
> score-elf-gcc: internal compiler error: Segmentation fault (program cc1)
> 0x40c073 execute
> ../../gcc/gcc/gcc.c:2848
> 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[1]: *** [block/elevator.o] Error 4
> make: *** [block/elevator.o] Error 2
>
> Do you see that as well ?
>
> This is with
>
> GNU assembler version 2.24.51 (score-elf) using BFD version (GNU Binutils) 2.24.51.20140622
>
> and gcc configured with:
>
> Configured with: ../gcc/configure --prefix=/opt/kernel/score --program-prefix=score-elf- \
> --target=score-elf --without-header --disable-nls --enable-languages=c --disable-threads \
> --disable-shared --enable-werror=no target_configargs=enable_vtable_verify=yes \
> --enable-obsolete --disable-libssp --disable-libquadmath
>
> Tip of gcc source is commit d8686b0aa945a, tip of binutils source is commit d17c74c1d41.
> Your assembler fix is included in this version of binutils.
>
Never mind, turns out I get score:defconfig to compile when using the tip of the gcc 4.9 branch.
Guenter
On 06/22/2014 01:09 AM, Lennox Wu wrote:
> Hi Chen,
> Do you find other modules except device modules cause issues of compiling?
> The applications of Score are limited. Acutally, some errors never occur
> in the limited applications, for example, the conbination consists of
> Score and the timer of SuperH. I'm not sure we should handle this kind
> of error.
> If the rule is that we should make sure "all" modules can be compiled
> with Score, we will do it.
> However, we still thanks for your check.
>
Other architectures don't care about buildability of allmodconfig or allyesconfig
(arm is a good [or maybe bad] example), so it is for sure not mandatory.
On the other side, fixing such problems - especially when you have someone
doing it for you - may prevent problems down the road, so while not mandatory
I consider it a useful goal to achieve.
If there is a driver which doesn't make sense to build at all, such as the SuperH
timer driver mentioned above, it can always be excluded from building with Kconfig.
If that causes opposition for some reason, you can still ignore that it fails
to build.
Guenter
On 06/22/2014 11:02 PM, Guenter Roeck wrote:
> On 06/22/2014 07:53 AM, Guenter Roeck wrote:
>> I did that, and managed to build gcc.
>>
>> However, when trying to compile score defconfig, I get internal
>> compiler errors in cc1
>> when compiling drivers/tty/tty_mutex.o and block/elevator.o.
>>
>> CC block/elevator.o
>> score-elf-gcc: internal compiler error: Segmentation fault (program cc1)
>> 0x40c073 execute
>> ../../gcc/gcc/gcc.c:2848
>> 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[1]: *** [block/elevator.o] Error 4
>> make: *** [block/elevator.o] Error 2
>>
>> Do you see that as well ?
>>
>> This is with
>>
>> GNU assembler version 2.24.51 (score-elf) using BFD version (GNU
>> Binutils) 2.24.51.20140622
>>
>> and gcc configured with:
>>
>> Configured with: ../gcc/configure --prefix=/opt/kernel/score
>> --program-prefix=score-elf- \
>> --target=score-elf --without-header --disable-nls --enable-languages=c
>> --disable-threads \
>> --disable-shared --enable-werror=no
>> target_configargs=enable_vtable_verify=yes \
>> --enable-obsolete --disable-libssp --disable-libquadmath
>>
>> Tip of gcc source is commit d8686b0aa945a, tip of binutils source is
>> commit d17c74c1d41.
>> Your assembler fix is included in this version of binutils.
>>
>
> Never mind, turns out I get score:defconfig to compile when using the
> tip of the gcc 4.9 branch.
>
> Guenter
>
OK, I shall try defconfig for it (originally, I try allmodconfig, not
find this issue), and try to solve it, hope (although I am not quite
sure), I can finish within this month (2014-06-30).
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
On 06/23/2014 12:28 AM, Guenter Roeck wrote:
> On 06/22/2014 01:09 AM, Lennox Wu wrote:
>> Hi Chen,
>> Do you find other modules except device modules cause issues of
>> compiling?
>> The applications of Score are limited. Acutally, some errors never occur
>> in the limited applications, for example, the conbination consists of
>> Score and the timer of SuperH. I'm not sure we should handle this kind
>> of error.
>> If the rule is that we should make sure "all" modules can be compiled
>> with Score, we will do it.
>> However, we still thanks for your check.
>>
>
> Other architectures don't care about buildability of allmodconfig or
> allyesconfig
> (arm is a good [or maybe bad] example), so it is for sure not mandatory.
> On the other side, fixing such problems - especially when you have someone
> doing it for you - may prevent problems down the road, so while not
> mandatory
> I consider it a useful goal to achieve.
>
> If there is a driver which doesn't make sense to build at all, such as
> the SuperH
> timer driver mentioned above, it can always be excluded from building
> with Kconfig.
> If that causes opposition for some reason, you can still ignore that it
> fails
> to build.
>
Yeah, what Guenter said is fine to me.
Although allmodconfig is not mandatory, it is still a useful goal to
achieve.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
Yes, it's the reason we still thank Chen's checking.
Arbitrary configurations except the default configure are not
guaranteed to pass compiling.
To discover combinations which doesn't make sense might weast Chen's time.
Best,
Lennox
2014-06-23 0:28 GMT+08:00 Guenter Roeck <[email protected]>:
> On 06/22/2014 01:09 AM, Lennox Wu wrote:
>>
>> Hi Chen,
>> Do you find other modules except device modules cause issues of compiling?
>> The applications of Score are limited. Acutally, some errors never occur
>> in the limited applications, for example, the conbination consists of
>> Score and the timer of SuperH. I'm not sure we should handle this kind
>> of error.
>> If the rule is that we should make sure "all" modules can be compiled
>> with Score, we will do it.
>> However, we still thanks for your check.
>>
>
> Other architectures don't care about buildability of allmodconfig or
> allyesconfig
> (arm is a good [or maybe bad] example), so it is for sure not mandatory.
> On the other side, fixing such problems - especially when you have someone
> doing it for you - may prevent problems down the road, so while not
> mandatory
> I consider it a useful goal to achieve.
>
> If there is a driver which doesn't make sense to build at all, such as the
> SuperH
> timer driver mentioned above, it can always be excluded from building with
> Kconfig.
> If that causes opposition for some reason, you can still ignore that it
> fails
> to build.
>
> Guenter
>
Sorry for the typo
.....
To discover combinations which doesn't make sense might waste Chen's time.
....
2014-06-23 11:07 GMT+08:00 Chen Gang <[email protected]>:
> On 06/23/2014 12:28 AM, Guenter Roeck wrote:
>> On 06/22/2014 01:09 AM, Lennox Wu wrote:
>>> Hi Chen,
>>> Do you find other modules except device modules cause issues of
>>> compiling?
>>> The applications of Score are limited. Acutally, some errors never occur
>>> in the limited applications, for example, the conbination consists of
>>> Score and the timer of SuperH. I'm not sure we should handle this kind
>>> of error.
>>> If the rule is that we should make sure "all" modules can be compiled
>>> with Score, we will do it.
>>> However, we still thanks for your check.
>>>
>>
>> Other architectures don't care about buildability of allmodconfig or
>> allyesconfig
>> (arm is a good [or maybe bad] example), so it is for sure not mandatory.
>> On the other side, fixing such problems - especially when you have someone
>> doing it for you - may prevent problems down the road, so while not
>> mandatory
>> I consider it a useful goal to achieve.
>>
>> If there is a driver which doesn't make sense to build at all, such as
>> the SuperH
>> timer driver mentioned above, it can always be excluded from building
>> with Kconfig.
>> If that causes opposition for some reason, you can still ignore that it
>> fails
>> to build.
>>
>
> Yeah, what Guenter said is fine to me.
>
> Although allmodconfig is not mandatory, it is still a useful goal to
> achieve.
>
>
> Thanks.
> --
> Chen Gang
>
> Open, share, and attitude like air, water, and life which God blessed
On 06/23/2014 11:10 AM, Lennox Wu wrote:
> Yes, it's the reason we still thank Chen's checking.
> Arbitrary configurations except the default configure are not
> guaranteed to pass compiling.
> To discover combinations which doesn't make sense might weast Chen's time.
>
It does not waste my time resource (at least, I perform open source
patches during my free time). And cross-compile all architectures with
allmodconfig can:
- let architectures a little better than before.
- let other modules within kernel a little better than before.
- may let open source cross-compiler a little better than before.
And for me, I also can learn much during perform these things.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
On Sun, 22 Jun 2014, Chen Gang wrote:
> diff --git a/arch/score/include/uapi/asm/ptrace.h b/arch/score/include/uapi/asm/ptrace.h
> index f59771a..7a0ead9 100644
> --- a/arch/score/include/uapi/asm/ptrace.h
> +++ b/arch/score/include/uapi/asm/ptrace.h
> @@ -4,16 +4,16 @@
> #define PTRACE_GETREGS 12
> #define PTRACE_SETREGS 13
>
> -#define PC 32
> -#define CONDITION 33
> -#define ECR 34
> -#define EMA 35
> -#define CEH 36
> -#define CEL 37
> -#define COUNTER 38
> -#define LDCR 39
> -#define STCR 40
> -#define PSR 41
> +#define SCORE_PC 32
> +#define SCORE_CONDITION 33
> +#define SCORE_ECR 34
> +#define SCORE_EMA 35
> +#define SCORE_CEH 36
> +#define SOCRE_CEL 37
SOCRE?
> +#define SCORE_COUNTER 38
> +#define SCORE_LDCR 39
> +#define SCORE_STCR 40
> +#define SCORE_PSR 41
>
> #define SINGLESTEP16_INSN 0x7006
> #define SINGLESTEP32_INSN 0x840C8000
This is a uapi header file, what was done to ensure this doesn't introduce
userspace breakage?
On 06/23/2014 05:38 PM, David Rientjes wrote:
> On Sun, 22 Jun 2014, Chen Gang wrote:
>
>> diff --git a/arch/score/include/uapi/asm/ptrace.h b/arch/score/include/uapi/asm/ptrace.h
>> index f59771a..7a0ead9 100644
>> --- a/arch/score/include/uapi/asm/ptrace.h
>> +++ b/arch/score/include/uapi/asm/ptrace.h
>> @@ -4,16 +4,16 @@
>> #define PTRACE_GETREGS 12
>> #define PTRACE_SETREGS 13
>>
>> -#define PC 32
>> -#define CONDITION 33
>> -#define ECR 34
>> -#define EMA 35
>> -#define CEH 36
>> -#define CEL 37
>> -#define COUNTER 38
>> -#define LDCR 39
>> -#define STCR 40
>> -#define PSR 41
>> +#define SCORE_PC 32
>> +#define SCORE_CONDITION 33
>> +#define SCORE_ECR 34
>> +#define SCORE_EMA 35
>> +#define SCORE_CEH 36
>> +#define SOCRE_CEL 37
>
> SOCRE?
>
OH, typo issue, thanks.
>> +#define SCORE_COUNTER 38
>> +#define SCORE_LDCR 39
>> +#define SCORE_STCR 40
>> +#define SCORE_PSR 41
>>
>> #define SINGLESTEP16_INSN 0x7006
>> #define SINGLESTEP32_INSN 0x840C8000
>
> This is a uapi header file, what was done to ensure this doesn't introduce
> userspace breakage?
>
Do you have any new idea for it, since you have question?
For me, one solving way is: use "#if defined(__KERNEL__) &&
defined(__LINUX__)" for check whether need a prefix (e.g. 'SCORE_') for it.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
On 06/23/2014 11:03 AM, Chen Gang wrote:
> On 06/22/2014 11:02 PM, Guenter Roeck wrote:
>> On 06/22/2014 07:53 AM, Guenter Roeck wrote:
>>> I did that, and managed to build gcc.
>>>
>>> However, when trying to compile score defconfig, I get internal
>>> compiler errors in cc1
>>> when compiling drivers/tty/tty_mutex.o and block/elevator.o.
>>>
>>> CC block/elevator.o
>>> score-elf-gcc: internal compiler error: Segmentation fault (program cc1)
>>> 0x40c073 execute
>>> ../../gcc/gcc/gcc.c:2848
>>> 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[1]: *** [block/elevator.o] Error 4
>>> make: *** [block/elevator.o] Error 2
>>>
>>> Do you see that as well ?
>>>
>>> This is with
>>>
>>> GNU assembler version 2.24.51 (score-elf) using BFD version (GNU
>>> Binutils) 2.24.51.20140622
>>>
>>> and gcc configured with:
>>>
>>> Configured with: ../gcc/configure --prefix=/opt/kernel/score
>>> --program-prefix=score-elf- \
>>> --target=score-elf --without-header --disable-nls --enable-languages=c
>>> --disable-threads \
>>> --disable-shared --enable-werror=no
>>> target_configargs=enable_vtable_verify=yes \
>>> --enable-obsolete --disable-libssp --disable-libquadmath
>>>
>>> Tip of gcc source is commit d8686b0aa945a, tip of binutils source is
>>> commit d17c74c1d41.
>>> Your assembler fix is included in this version of binutils.
>>>
Can we repeated this issue, or it is random? I have try it use my
current gcc version, it has no issue.
If it can be repeated in the latest version, I shall use version compine
(and try step by step) to fix it.
If real random issue, if possible, please help repeated and generate
coredump file, and put it to a place to let me get back for analysing.
Thanks.
>>
>> Never mind, turns out I get score:defconfig to compile when using the
>> tip of the gcc 4.9 branch.
>>
>> Guenter
>>
>
> OK, I shall try defconfig for it (originally, I try allmodconfig, not
> find this issue), and try to solve it, hope (although I am not quite
> sure), I can finish within this month (2014-06-30).
>
>
> Thanks.
>
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
On 06/24/2014 06:24 AM, Chen Gang wrote:
> On 06/23/2014 11:03 AM, Chen Gang wrote:
>> On 06/22/2014 11:02 PM, Guenter Roeck wrote:
>>> On 06/22/2014 07:53 AM, Guenter Roeck wrote:
>>>> I did that, and managed to build gcc.
>>>>
>>>> However, when trying to compile score defconfig, I get internal
>>>> compiler errors in cc1
>>>> when compiling drivers/tty/tty_mutex.o and block/elevator.o.
>>>>
>>>> CC block/elevator.o
>>>> score-elf-gcc: internal compiler error: Segmentation fault (program cc1)
>>>> 0x40c073 execute
>>>> ../../gcc/gcc/gcc.c:2848
>>>> 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[1]: *** [block/elevator.o] Error 4
>>>> make: *** [block/elevator.o] Error 2
>>>>
>>>> Do you see that as well ?
>>>>
>>>> This is with
>>>>
>>>> GNU assembler version 2.24.51 (score-elf) using BFD version (GNU
>>>> Binutils) 2.24.51.20140622
>>>>
>>>> and gcc configured with:
>>>>
>>>> Configured with: ../gcc/configure --prefix=/opt/kernel/score
>>>> --program-prefix=score-elf- \
>>>> --target=score-elf --without-header --disable-nls --enable-languages=c
>>>> --disable-threads \
>>>> --disable-shared --enable-werror=no
>>>> target_configargs=enable_vtable_verify=yes \
>>>> --enable-obsolete --disable-libssp --disable-libquadmath
>>>>
>>>> Tip of gcc source is commit d8686b0aa945a, tip of binutils source is
>>>> commit d17c74c1d41.
>>>> Your assembler fix is included in this version of binutils.
>>>>
>
> Can we repeated this issue, or it is random? I have try it use my
> current gcc version, it has no issue.
>
> If it can be repeated in the latest version, I shall use version compine
> (and try step by step) to fix it.
>
> If real random issue, if possible, please help repeated and generate
> coredump file, and put it to a place to let me get back for analysing.
>
I got the same error each time. You should be able to reproduce it by
checking out the latest gcc. If that doesn't produce the error, try
checking out sha d8686b0aa945a. I didn't keep that compiler after the tip
of the gcc 4.9 branch worked, so I'd have to rebuild it myself
to reproduce it myself.
Note that compilation of libssp failed with d8686b0aa945a, which is why
I disabled it. I didn't try to build it with 4.9.
Guenter
On 06/24/2014 10:44 PM, Guenter Roeck wrote:
> On 06/24/2014 06:24 AM, Chen Gang wrote:
>> On 06/23/2014 11:03 AM, Chen Gang wrote:
>>> On 06/22/2014 11:02 PM, Guenter Roeck wrote:
>>>> On 06/22/2014 07:53 AM, Guenter Roeck wrote:
>>>>> I did that, and managed to build gcc.
>>>>>
>>>>> However, when trying to compile score defconfig, I get internal
>>>>> compiler errors in cc1
>>>>> when compiling drivers/tty/tty_mutex.o and block/elevator.o.
>>>>>
>>>>> CC block/elevator.o
>>>>> score-elf-gcc: internal compiler error: Segmentation fault (program
>>>>> cc1)
>>>>> 0x40c073 execute
>>>>> ../../gcc/gcc/gcc.c:2848
>>>>> 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[1]: *** [block/elevator.o] Error 4
>>>>> make: *** [block/elevator.o] Error 2
>>>>>
>>>>> Do you see that as well ?
>>>>>
>>>>> This is with
>>>>>
>>>>> GNU assembler version 2.24.51 (score-elf) using BFD version (GNU
>>>>> Binutils) 2.24.51.20140622
>>>>>
>>>>> and gcc configured with:
>>>>>
>>>>> Configured with: ../gcc/configure --prefix=/opt/kernel/score
>>>>> --program-prefix=score-elf- \
>>>>> --target=score-elf --without-header --disable-nls --enable-languages=c
>>>>> --disable-threads \
>>>>> --disable-shared --enable-werror=no
>>>>> target_configargs=enable_vtable_verify=yes \
>>>>> --enable-obsolete --disable-libssp --disable-libquadmath
>>>>>
>>>>> Tip of gcc source is commit d8686b0aa945a, tip of binutils source is
>>>>> commit d17c74c1d41.
>>>>> Your assembler fix is included in this version of binutils.
>>>>>
>>
>> Can we repeated this issue, or it is random? I have try it use my
>> current gcc version, it has no issue.
>>
>> If it can be repeated in the latest version, I shall use version compine
>> (and try step by step) to fix it.
>>
>> If real random issue, if possible, please help repeated and generate
>> coredump file, and put it to a place to let me get back for analysing.
>>
> I got the same error each time. You should be able to reproduce it by
> checking out the latest gcc. If that doesn't produce the error, try
> checking out sha d8686b0aa945a. I didn't keep that compiler after the tip
> of the gcc 4.9 branch worked, so I'd have to rebuild it myself
> to reproduce it myself.
>
> Note that compilation of libssp failed with d8686b0aa945a, which is why
> I disabled it. I didn't try to build it with 4.9.
>
Thank you very much for your work.
It is my chance to fix gcc issues which I have planed, I shall continue
based on it, hope I can finish within this month (within 2014-06-30).
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
On 06/25/2014 08:28 AM, Chen Gang wrote:
> On 06/24/2014 10:44 PM, Guenter Roeck wrote:
>> On 06/24/2014 06:24 AM, Chen Gang wrote:
>>> On 06/23/2014 11:03 AM, Chen Gang wrote:
>>>> On 06/22/2014 11:02 PM, Guenter Roeck wrote:
>>>>> On 06/22/2014 07:53 AM, Guenter Roeck wrote:
>>>>>> I did that, and managed to build gcc.
>>>>>>
>>>>>> However, when trying to compile score defconfig, I get internal
>>>>>> compiler errors in cc1
>>>>>> when compiling drivers/tty/tty_mutex.o and block/elevator.o.
>>>>>>
>>>>>> CC block/elevator.o
>>>>>> score-elf-gcc: internal compiler error: Segmentation fault (program
>>>>>> cc1)
>>>>>> 0x40c073 execute
>>>>>> ../../gcc/gcc/gcc.c:2848
>>>>>> 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[1]: *** [block/elevator.o] Error 4
>>>>>> make: *** [block/elevator.o] Error 2
>>>>>>
>>>>>> Do you see that as well ?
>>>>>>
>>>>>> This is with
>>>>>>
>>>>>> GNU assembler version 2.24.51 (score-elf) using BFD version (GNU
>>>>>> Binutils) 2.24.51.20140622
>>>>>>
>>>>>> and gcc configured with:
>>>>>>
>>>>>> Configured with: ../gcc/configure --prefix=/opt/kernel/score
>>>>>> --program-prefix=score-elf- \
>>>>>> --target=score-elf --without-header --disable-nls --enable-languages=c
>>>>>> --disable-threads \
>>>>>> --disable-shared --enable-werror=no
>>>>>> target_configargs=enable_vtable_verify=yes \
>>>>>> --enable-obsolete --disable-libssp --disable-libquadmath
>>>>>>
>>>>>> Tip of gcc source is commit d8686b0aa945a, tip of binutils source is
>>>>>> commit d17c74c1d41.
>>>>>> Your assembler fix is included in this version of binutils.
>>>>>>
>>>
>>> Can we repeated this issue, or it is random? I have try it use my
>>> current gcc version, it has no issue.
>>>
>>> If it can be repeated in the latest version, I shall use version compine
>>> (and try step by step) to fix it.
>>>
>>> If real random issue, if possible, please help repeated and generate
>>> coredump file, and put it to a place to let me get back for analysing.
>>>
>> I got the same error each time. You should be able to reproduce it by
>> checking out the latest gcc. If that doesn't produce the error, try
>> checking out sha d8686b0aa945a. I didn't keep that compiler after the tip
>> of the gcc 4.9 branch worked, so I'd have to rebuild it myself
>> to reproduce it myself.
>>
>> Note that compilation of libssp failed with d8686b0aa945a, which is why
>> I disabled it. I didn't try to build it with 4.9.
>>
And I guess, I have found the root cause, and sent related information
to gcc mailing list (also cc to you). And one temporary fix below (can
cross compile score defconfig successfully for latest gcc):
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index def10a2..af49601 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -2300,15 +2300,6 @@ merge_decls (tree newdecl, tree olddecl, tree newtype, tree oldtype)
if (CODE_CONTAINS_STRUCT (TREE_CODE (olddecl), TS_DECL_WITH_VIS))
{
- /* Merge the section attribute.
- We want to issue an error if the sections conflict but that
- must be done later in decl_attributes since we are called
- before attributes are assigned. */
- if ((DECL_EXTERNAL (olddecl) || TREE_PUBLIC (olddecl) || TREE_STATIC (olddecl))
- && DECL_SECTION_NAME (newdecl) == NULL
- && DECL_SECTION_NAME (olddecl))
- set_decl_section_name (newdecl, DECL_SECTION_NAME (olddecl));
-
/* Copy the assembler name.
Currently, it can only be defined in the prototype. */
COPY_DECL_ASSEMBLER_NAME (olddecl, newdecl);
I shall continue for it, and provide the final property fix for it.
Thanks.
>
> Thank you very much for your work.
>
> It is my chance to fix gcc issues which I have planed, I shall continue
> based on it, hope I can finish within this month (within 2014-06-30).
>
>
> Thanks.
>
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
On 06/27/2014 06:12 PM, Chen Gang wrote:
> On 06/25/2014 08:28 AM, Chen Gang wrote:
>> On 06/24/2014 10:44 PM, Guenter Roeck wrote:
>>> On 06/24/2014 06:24 AM, Chen Gang wrote:
>>>> On 06/23/2014 11:03 AM, Chen Gang wrote:
>>>>> On 06/22/2014 11:02 PM, Guenter Roeck wrote:
>>>>>> On 06/22/2014 07:53 AM, Guenter Roeck wrote:
>>>>>>> I did that, and managed to build gcc.
>>>>>>>
>>>>>>> However, when trying to compile score defconfig, I get internal
>>>>>>> compiler errors in cc1
>>>>>>> when compiling drivers/tty/tty_mutex.o and block/elevator.o.
>>>>>>>
>>>>>>> CC block/elevator.o
>>>>>>> score-elf-gcc: internal compiler error: Segmentation fault (program
>>>>>>> cc1)
>>>>>>> 0x40c073 execute
>>>>>>> ../../gcc/gcc/gcc.c:2848
>>>>>>> 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[1]: *** [block/elevator.o] Error 4
>>>>>>> make: *** [block/elevator.o] Error 2
>>>>>>>
>>>>>>> Do you see that as well ?
>>>>>>>
>>>>>>> This is with
>>>>>>>
>>>>>>> GNU assembler version 2.24.51 (score-elf) using BFD version (GNU
>>>>>>> Binutils) 2.24.51.20140622
>>>>>>>
>>>>>>> and gcc configured with:
>>>>>>>
>>>>>>> Configured with: ../gcc/configure --prefix=/opt/kernel/score
>>>>>>> --program-prefix=score-elf- \
>>>>>>> --target=score-elf --without-header --disable-nls --enable-languages=c
>>>>>>> --disable-threads \
>>>>>>> --disable-shared --enable-werror=no
>>>>>>> target_configargs=enable_vtable_verify=yes \
>>>>>>> --enable-obsolete --disable-libssp --disable-libquadmath
>>>>>>>
>>>>>>> Tip of gcc source is commit d8686b0aa945a, tip of binutils source is
>>>>>>> commit d17c74c1d41.
>>>>>>> Your assembler fix is included in this version of binutils.
>>>>>>>
>>>>
>>>> Can we repeated this issue, or it is random? I have try it use my
>>>> current gcc version, it has no issue.
>>>>
>>>> If it can be repeated in the latest version, I shall use version compine
>>>> (and try step by step) to fix it.
>>>>
>>>> If real random issue, if possible, please help repeated and generate
>>>> coredump file, and put it to a place to let me get back for analysing.
>>>>
>>> I got the same error each time. You should be able to reproduce it by
>>> checking out the latest gcc. If that doesn't produce the error, try
>>> checking out sha d8686b0aa945a. I didn't keep that compiler after the tip
>>> of the gcc 4.9 branch worked, so I'd have to rebuild it myself
>>> to reproduce it myself.
>>>
>>> Note that compilation of libssp failed with d8686b0aa945a, which is why
>>> I disabled it. I didn't try to build it with 4.9.
>>>
gcc members response quickly, and confirm it, the related fix patch
which is made by a gcc member and I, have applied into latest gcc source
code.
So... I finished it within this month (this thread will be end)! :-)
Thanks.
>
> And I guess, I have found the root cause, and sent related information
> to gcc mailing list (also cc to you). And one temporary fix below (can
> cross compile score defconfig successfully for latest gcc):
>
> diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
> index def10a2..af49601 100644
> --- a/gcc/c/c-decl.c
> +++ b/gcc/c/c-decl.c
> @@ -2300,15 +2300,6 @@ merge_decls (tree newdecl, tree olddecl, tree newtype, tree oldtype)
>
> if (CODE_CONTAINS_STRUCT (TREE_CODE (olddecl), TS_DECL_WITH_VIS))
> {
> - /* Merge the section attribute.
> - We want to issue an error if the sections conflict but that
> - must be done later in decl_attributes since we are called
> - before attributes are assigned. */
> - if ((DECL_EXTERNAL (olddecl) || TREE_PUBLIC (olddecl) || TREE_STATIC (olddecl))
> - && DECL_SECTION_NAME (newdecl) == NULL
> - && DECL_SECTION_NAME (olddecl))
> - set_decl_section_name (newdecl, DECL_SECTION_NAME (olddecl));
> -
> /* Copy the assembler name.
> Currently, it can only be defined in the prototype. */
> COPY_DECL_ASSEMBLER_NAME (olddecl, newdecl);
>
> I shall continue for it, and provide the final property fix for it.
>
> Thanks.
>
>>
>> Thank you very much for your work.
>>
>> It is my chance to fix gcc issues which I have planed, I shall continue
>> based on it, hope I can finish within this month (within 2014-06-30).
>>
>>
>> Thanks.
>>
>
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed