Re: [Consult] cris: arch-v10: About $dtp0 register

[Chen Gang]

On 07/07/2015 08:05 PM, Hans-Peter Nilsson wrote:
>> From: Chen Gang <xili_gchen_5257@xxxxxxxxxxx>
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/