Hello Maintainers:
I want to consult, whether arch-v10 supports $dtp0 register:
- Kernel has already used it in arch/cris/arch-v10/kernel/kgdb.c.
- But upstream gas 2.25.51 can not recognize it for arch-v10, for the
same kgdb.s file which contents $dtp0:
"/upstream/release-cris/bin/cris-gchen-linux-as ./kgdb.s -o kgdb.o" will be ok.
"/upstream/release-cris/bin/cris-gchen-linux-as --march=v10 ./kgdb.s -o kgdb.o" will cause "Error: Illegal operands".
For me, I guess, it is upstream toolchain's issue, but I have no the
related ISA documentations (common ISA and v10 special ISA), so at
present I can not be sure about it (related informations are welcomed).
And after this issue, excluding warnings, the cris next-20150702 can
pass allmodconfig with the current latest upstream master branch
toolchain. :-)
Welcome any ideas, suggestions and completions.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
> From: Chen Gang <[email protected]>
> Date: Sun, 5 Jul 2015 00:30:48 +0200
> Hello Maintainers:
>
> I want to consult, whether arch-v10 supports $dtp0 register:
Use your favorite search engine for "Axis ETRAX 100 LX
programmers manual". I just did and got the good news that the
inteded PDF was the top item found. This document has all the
details you'll ever need for CRIS up to and including CRIS v10
(yes, that's the canonical spelling, not "CRISv10"). In chapter
"1.1 Registers", the special registers are listed. Neither DTP0
nor DTP1 are mentioned there. There is an appendix titled "The
ETRAX 4", listing details to a predecessor version. The DTP0
register is mentioned there in "7.2 Special Registers"; it's
special register P12.
To cut the story short for most, this is an ETRAX 4 register
connected to DMA logic, not supported by ETRAX 100 LX. If you
for some reason need to refer to the special register *as such*,
it can be accessed by the name P12, but the issue here is
actually with BAR, the breakpoint address register.
> - Kernel has already used it in arch/cris/arch-v10/kernel/kgdb.c.
If you also read the comment there, at both uses (assuming you
read the same as the downstream I read), it says "P12, register
BAR, assembler might not know BAR". It apparently alludes to
special register BAR not being accessible in the assembler at
that time (possibly by speculation rather than inspection; I
guess that's the case). So, IMHO a better question for your
intentions would have focused on the code in kgdb.c, not asking
about the DTP0 register as such.
If you change the $dtp0 to $bar or $p12, I believe you will get
the intended result. The "$bar" name has worked for at least 11
years, probably 15, with the -march=v10 option but likely also
without it. Cf. opcodes/cris-opc.c in the shared gdb and
binutils git for history. (Yes, the CVS history *was* carried
over at the git conversion.)
>
> - But upstream gas 2.25.51 can not recognize it for arch-v10, for the
> same kgdb.s file which contents $dtp0:
>
> "/upstream/release-cris/bin/cris-gchen-linux-as ./kgdb.s -o kgdb.o" will be ok.
> "/upstream/release-cris/bin/cris-gchen-linux-as --march=v10 ./kgdb.s -o kgdb.o" will cause "Error: Illegal operands".
I'm guessing "recent" changes (later than the last ten years ;-)
somehow added an -march=v10 directly or indirectly, such that
$dtp0 was no longer accepted (as it isn't "supported" for CRIS v10).
> For me, I guess, it is upstream toolchain's issue, but I have no the
> related ISA documentations (common ISA and v10 special ISA), so at
> present I can not be sure about it (related informations are welcomed).
It's a downstream use issue, which could be fixed without prior
knowledge using only web resources. More things are, than people
usually believe.
> And after this issue, excluding warnings, the cris next-20150702 can
> pass allmodconfig with the current latest upstream master branch
> toolchain. :-)
>
>
> Welcome any ideas, suggestions and completions.
As a collateral, can I have an "upstream" GIT (slug and) commit
id I can use to compile a CRIS v10 kernel, possibly modulo this
issue? I need to use the kernel as a test-case for a gcc issue.
I'll use Segher Boessenkool "buildall" kernelbuild scripts, but
I'm missing a compilable kernel commit-id. (No, I haven't
actually followed my own advice but by your email I'm guessing
CRIS v10 isn't currently compilable.)
>
> Thanks.
> --
> Chen Gang
>
> Open, share, and attitude like air, water, and life which God blessed
>
brgds, H-P
On 07/07/2015 08:05 PM, Hans-Peter Nilsson wrote:
>> From: Chen Gang <[email protected]>
>> Date: Sun, 5 Jul 2015 00:30:48 +0200
>
>> Hello Maintainers:
>>
>> I want to consult, whether arch-v10 supports $dtp0 register:
>
> Use your favorite search engine for "Axis ETRAX 100 LX
> programmers manual". I just did and got the good news that the
> inteded PDF was the top item found. This document has all the
> details you'll ever need for CRIS up to and including CRIS v10
> (yes, that's the canonical spelling, not "CRISv10"). In chapter
> "1.1 Registers", the special registers are listed. Neither DTP0
> nor DTP1 are mentioned there. There is an appendix titled "The
> ETRAX 4", listing details to a predecessor version. The DTP0
> register is mentioned there in "7.2 Special Registers"; it's
> special register P12.
>
> To cut the story short for most, this is an ETRAX 4 register
> connected to DMA logic, not supported by ETRAX 100 LX. If you
> for some reason need to refer to the special register *as such*,
> it can be accessed by the name P12, but the issue here is
> actually with BAR, the breakpoint address register.
>
OK, thank you very much for your details information.
>> - Kernel has already used it in arch/cris/arch-v10/kernel/kgdb.c.
>
> If you also read the comment there, at both uses (assuming you
> read the same as the downstream I read), it says "P12, register
> BAR, assembler might not know BAR". It apparently alludes to
> special register BAR not being accessible in the assembler at
> that time (possibly by speculation rather than inspection; I
> guess that's the case). So, IMHO a better question for your
> intentions would have focused on the code in kgdb.c, not asking
> about the DTP0 register as such.
>
> If you change the $dtp0 to $bar or $p12, I believe you will get
> the intended result. The "$bar" name has worked for at least 11
> years, probably 15, with the -march=v10 option but likely also
> without it. Cf. opcodes/cris-opc.c in the shared gdb and
> binutils git for history. (Yes, the CVS history *was* carried
> over at the git conversion.)
>
For me, after reading the opcodes/cris-opc.c, we are sure p12, dtp0,
and bar are the same, and can be supported by binutils (just like the
comments in kgdb.c of kernel). And kernel prefer the dtp0 among them.
So, I say: "kernel has already used it".
>>
>> - But upstream gas 2.25.51 can not recognize it for arch-v10, for the
>> same kgdb.s file which contents $dtp0:
>>
>> "/upstream/release-cris/bin/cris-gchen-linux-as ./kgdb.s -o kgdb.o" will be ok.
>> "/upstream/release-cris/bin/cris-gchen-linux-as --march=v10 ./kgdb.s -o kgdb.o" will cause "Error: Illegal operands".
>
> I'm guessing "recent" changes (later than the last ten years ;-)
> somehow added an -march=v10 directly or indirectly, such that
> $dtp0 was no longer accepted (as it isn't "supported" for CRIS v10).
>
OK, thanks.
>> For me, I guess, it is upstream toolchain's issue, but I have no the
>> related ISA documentations (common ISA and v10 special ISA), so at
>> present I can not be sure about it (related informations are welcomed).
>
> It's a downstream use issue, which could be fixed without prior
> knowledge using only web resources. More things are, than people
> usually believe.
>
Firstly, if one tries to solve the related issues for the related
organization, he/she can ask questions to the related organization.
And yes, for me, most of questions (more than 80%) can be solved by
using only web resources, but it is still reasonable to ask questions
in some cases:
- If persons are newbies (e.g. I am a newbie for cris), for them, it is
not quite easy to solve issues by using only web resources (they can,
but that needs much un-nessesary time resources).
- Through asking question, he/she not only can save his/her time
resources, but also can get more valuable details, and let the
contribution better (so for me, it should be 'consult').
- Asking questions can let the corporation better and better between
he/she and the organization.
But of cause, the contributor should not only depend on the reply: if
get no reply, he/she should continue analysing (which will spend more
un-necessary time resources).
>> And after this issue, excluding warnings, the cris next-20150702 can
>> pass allmodconfig with the current latest upstream master branch
>> toolchain. :-)
>>
>>
>> Welcome any ideas, suggestions and completions.
>
> As a collateral, can I have an "upstream" GIT (slug and) commit
> id I can use to compile a CRIS v10 kernel, possibly modulo this
> issue? I need to use the kernel as a test-case for a gcc issue.
> I'll use Segher Boessenkool "buildall" kernelbuild scripts, but
> I'm missing a compilable kernel commit-id. (No, I haven't
> actually followed my own advice but by your email I'm guessing
> CRIS v10 isn't currently compilable.)
>
Excuse me, I am not quite understand your meaning, welcome additional
details explanations.
And for me, hope the details below are useful for what you said above (
but I am not quite sure).
- I use the linux-next git tree which everyone can "git clone":
"git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git",
and I often use "git remote update" to get the latest release.
- With the related patches I have sent, the "git tag" next-20150702 can
pass allmodconfig with the cross raw compiler (allmodconfig selects
CRIS v10).
- Normally, I send patches to kernel mailing list with "Signed-of-by"
with my own mail address by "git commit -a -s". If the patch passes
review, it will be integrated into linux-next tree, then to master.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
On 7/9/15 08:44, Chen Gang wrote:
> On 07/07/2015 08:05 PM, Hans-Peter Nilsson wrote:
>>
>> As a collateral, can I have an "upstream" GIT (slug and) commit
>> id I can use to compile a CRIS v10 kernel, possibly modulo this
>> issue? I need to use the kernel as a test-case for a gcc issue.
>> I'll use Segher Boessenkool "buildall" kernelbuild scripts, but
>> I'm missing a compilable kernel commit-id. (No, I haven't
>> actually followed my own advice but by your email I'm guessing
>> CRIS v10 isn't currently compilable.)
>>
The latest upstream cris gcc will cause issue for next-20150720 with
allmodconfig (although it can let next-20150702 pass allmodconfig):
CC [M] kernel/rcu/rcutorture.o
In file included from include/linux/rcupdate.h:429:0,
from include/linux/srcu.h:33,
from include/linux/notifier.h:15,
from include/linux/memory_hotplug.h:6,
from include/linux/mmzone.h:789,
from include/linux/gfp.h:5,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from kernel/rcu/rcutorture.c:28:
include/linux/rcutiny.h: In function 'rcu_barrier_sched':
include/linux/rcutiny.h:55:20: internal compiler error: Segmentation fault
static inline void rcu_barrier_sched(void)
^
0xad879f crash_signal
../../gcc/gcc/toplev.c:352
0xbf0fb8 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:2857
0xbf0fb8 fold_builtin_alloca_with_align
../../gcc/gcc/tree-ssa-ccp.c:2110
0xbf0fb8 ccp_fold_stmt
../../gcc/gcc/tree-ssa-ccp.c:2215
0xc7f8da substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-propagate.c:1226
0xe448f7 dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:177
0xc7f0d9 substitute_and_fold(tree_node* (*)(tree_node*), bool (*)(gimple_stmt_iterator*), bool)
../../gcc/gcc/tree-ssa-propagate.c:1319
0xbe967c ccp_finalize
../../gcc/gcc/tree-ssa-ccp.c:951
0xbe967c do_ssa_ccp
../../gcc/gcc/tree-ssa-ccp.c:2410
0xbe967c execute
../../gcc/gcc/tree-ssa-ccp.c:2442 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]: *** [kernel/rcu/rcutorture.o] Error 1
make[1]: *** [kernel/rcu] Error 2
make: *** [kernel] Error 2
[root@localhost build-gcc-cris]# /upstream/release-cris/bin/cris-gchen-linux-gcc -v
Using built-in specs.
COLLECT_GCC=/upstream/release-cris/bin/cris-gchen-linux-gcc
COLLECT_LTO_WRAPPER=/upstream/release-cris/libexec/gcc/cris-gchen-linux/6.0.0/lto-wrapper
Target: cris-gchen-linux
Configured with: ../gcc/configure --target=cris-gchen-linux --disable-nls --enable-languages=c --disable-threads --disable-shared --disable-libssp --disable-libquadmath --disable-
libgomp --disable-libatomic --prefix=/upstream/release-cris --without-headers
Thread model: single
gcc version 6.0.0 20150720 (experimental) (GCC)
If no any additional response, I shall try to fix it in the next month.
Thanks.
>
> Excuse me, I am not quite understand your meaning, welcome additional
> details explanations.
>
> And for me, hope the details below are useful for what you said above (
> but I am not quite sure).
>
> - I use the linux-next git tree which everyone can "git clone":
> "git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git",
> and I often use "git remote update" to get the latest release.
>
> - With the related patches I have sent, the "git tag" next-20150702 can
> pass allmodconfig with the cross raw compiler (allmodconfig selects
> CRIS v10).
>
> - Normally, I send patches to kernel mailing list with "Signed-of-by"
> with my own mail address by "git commit -a -s". If the patch passes
> review, it will be integrated into linux-next tree, then to master.
>
> Thanks.
>
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
> From: Chen Gang <[email protected]>
> Date: Thu, 9 Jul 2015 02:44:26 +0200
>On 07/07/2015 08:05 PM, Hans-Peter Nilsson wrote:
> > As a collateral, can I have an "upstream" GIT (slug and) commit
> > id I can use to compile a CRIS v10 kernel, possibly modulo this
> > issue? I need to use the kernel as a test-case for a gcc issue.
> > I'll use Segher Boessenkool "buildall" kernelbuild scripts, but
> > I'm missing a compilable kernel commit-id. (No, I haven't
> > actually followed my own advice but by your email I'm guessing
> > CRIS v10 isn't currently compilable.)
> >
>
> Excuse me, I am not quite understand your meaning, welcome additional
> details explanations.
I'll use other words and less details: I have a gcc-bug for CRIS
v10 and CRIS v32 to investigate and need to use the kernel as a
test-case. So, I need to check out kernel sources that I know
will compile, as I know there are kernel issues with the CRIS
port(s) from time to time. I don't usually compile the kernel.
> And for me, hope the details below are useful for what you said above (
> but I am not quite sure).
>
> - I use the linux-next git tree which everyone can "git clone":
> "git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git",
> and I often use "git remote update" to get the latest release.
>
> - With the related patches I have sent, the "git tag" next-20150702 can
> pass allmodconfig with the cross raw compiler (allmodconfig selects
> CRIS v10).
Thank you, the git and the tag is exactly the information I need.
brgds, H-P
> From: Chen Gang <[email protected]>
> Date: Mon, 20 Jul 2015 23:32:52 +0200
> On 7/9/15 08:44, Chen Gang wrote:
> The latest upstream cris gcc will cause issue for next-20150720 with
> allmodconfig (although it can let next-20150702 pass allmodconfig):
>
> CC [M] kernel/rcu/rcutorture.o
[...]
> include/linux/rcutiny.h:55:20: internal compiler error: Segmentation fault
> static inline void rcu_barrier_sched(void)
> ^
> 0xad879f crash_signal
> ../../gcc/gcc/toplev.c:352
> 0xbf0fb8 tree_check(tree_node*, char const*, int, char const*, tree_code)
> ../../gcc/gcc/tree.h:2857
> 0xbf0fb8 fold_builtin_alloca_with_align
> ../../gcc/gcc/tree-ssa-ccp.c:2110
[...]
> If no any additional response, I shall try to fix it in the next month.
No need to enter a new bug report, this appears to be
<https://gcc.gnu.org/PR67055>. It is also observed for other
ports, at least with the original C++ test-case there. I added
a reduced rcutorture.c to the bug-report. Thanks.
brgds, H-P
On 8/5/15 12:32, Hans-Peter Nilsson wrote:
>> From: Chen Gang <[email protected]>
>> Date: Mon, 20 Jul 2015 23:32:52 +0200
>
>> On 7/9/15 08:44, Chen Gang wrote:
>> The latest upstream cris gcc will cause issue for next-20150720 with
>> allmodconfig (although it can let next-20150702 pass allmodconfig):
>>
>> CC [M] kernel/rcu/rcutorture.o
> [...]
>> include/linux/rcutiny.h:55:20: internal compiler error: Segmentation fault
>> static inline void rcu_barrier_sched(void)
>> ^
>> 0xad879f crash_signal
>> ../../gcc/gcc/toplev.c:352
>> 0xbf0fb8 tree_check(tree_node*, char const*, int, char const*, tree_code)
>> ../../gcc/gcc/tree.h:2857
>> 0xbf0fb8 fold_builtin_alloca_with_align
>> ../../gcc/gcc/tree-ssa-ccp.c:2110
> [...]
>
>> If no any additional response, I shall try to fix it in the next month.
>
> No need to enter a new bug report, this appears to be
> <https://gcc.gnu.org/PR67055>. It is also observed for other
> ports, at least with the original C++ test-case there. I added
> a reduced rcutorture.c to the bug-report. Thanks.
>
OK, thanks. :-)
And next, I shall try to cross compile kernel for another archs, hope I
can start in 2015-08-15 -- during these days I am trying tilegx qemu for
gcc testsuite (mainly for floating point insns and pending issues).
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
> From: Chen Gang <[email protected]>
> Date: Wed, 5 Aug 2015 16:39:00 +0200
> On 8/5/15 12:32, Hans-Peter Nilsson wrote:
> >> From: Chen Gang <[email protected]>
> >> Date: Mon, 20 Jul 2015 23:32:52 +0200
> >
> >> On 7/9/15 08:44, Chen Gang wrote:
> >> The latest upstream cris gcc will cause issue for next-20150720 with
> >> allmodconfig (although it can let next-20150702 pass allmodconfig):
> >>
> >> CC [M] kernel/rcu/rcutorture.o
> > [...]
> >> include/linux/rcutiny.h:55:20: internal compiler error: Segmentation fault
> >> static inline void rcu_barrier_sched(void)
> >> ^
> >> 0xad879f crash_signal
> >> ../../gcc/gcc/toplev.c:352
> >> 0xbf0fb8 tree_check(tree_node*, char const*, int, char const*, tree_code)
> >> ../../gcc/gcc/tree.h:2857
> >> 0xbf0fb8 fold_builtin_alloca_with_align
> >> ../../gcc/gcc/tree-ssa-ccp.c:2110
> > [...]
> >
> >> If no any additional response, I shall try to fix it in the next month.
> >
> > No need to enter a new bug report, this appears to be
> > <https://gcc.gnu.org/PR67055>. It is also observed for other
> > ports, at least with the original C++ test-case there. I added
> > a reduced rcutorture.c to the bug-report. Thanks.
> >
>
> OK, thanks. :-)
>
> And next, I shall try to cross compile kernel for another archs, hope I
> can start in 2015-08-15 -- during these days I am trying tilegx qemu for
> gcc testsuite (mainly for floating point insns and pending issues).
(Hopefully on-topic as the bug is likely to appear for multiple targets:)
Or pick up any gcc-6.0 snapshot later than or equal to r226616,
as a fix is now committed. I just verified that the fix covers
the original and reduced kernel test-cases. The fix is not on
the 5.x branch yet but I believe it is likely to be back-ported
in time for 5.3.
brgds, H-P