* [PATCH] arch: metag: lib: add "umoddi3.S" file for __umoddi3()
@ 2013-12-19 12:05 Chen Gang
2013-12-19 12:17 ` James Hogan
0 siblings, 1 reply; 9+ messages in thread
From: Chen Gang @ 2013-12-19 12:05 UTC (permalink / raw)
To: James Hogan, rostedt; +Cc: linux-kernel@vger.kernel.org, linux-metag
Use objdump to get "umoddi3.S" for __umoddi3(), the original binary
file is "gcc-4.2.4-final/gcc/libgcc/umoddi3.o" which is generated by
"gcc-4.2.4/gcc/libgcc2.c".
The relate error with allmodconfig:
MODPOST 2909 modules
ERROR: "__umoddi3" [drivers/target/target_core_mod.ko] undefined!
Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
arch/metag/kernel/metag_ksyms.c | 1 +
arch/metag/lib/Makefile | 1 +
arch/metag/lib/umoddi3.S | 367 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 369 insertions(+)
create mode 100644 arch/metag/lib/umoddi3.S
diff --git a/arch/metag/kernel/metag_ksyms.c b/arch/metag/kernel/metag_ksyms.c
index 215c94a..545eb1f 100644
--- a/arch/metag/kernel/metag_ksyms.c
+++ b/arch/metag/kernel/metag_ksyms.c
@@ -39,6 +39,7 @@ DECLARE_EXPORT(__modsi3);
DECLARE_EXPORT(__muldi3);
DECLARE_EXPORT(__cmpdi2);
DECLARE_EXPORT(__ucmpdi2);
+DECLARE_EXPORT(__umoddi3);
/* Maths functions */
EXPORT_SYMBOL(div_u64);
diff --git a/arch/metag/lib/Makefile b/arch/metag/lib/Makefile
index a41d24e..ae5cb41 100644
--- a/arch/metag/lib/Makefile
+++ b/arch/metag/lib/Makefile
@@ -20,3 +20,4 @@ lib-y += cmpdi2.o
lib-y += ucmpdi2.o
lib-y += ip_fast_csum.o
lib-y += checksum.o
+lib-y += umoddi3.o
diff --git a/arch/metag/lib/umoddi3.S b/arch/metag/lib/umoddi3.S
new file mode 100644
index 0000000..399b27b
--- /dev/null
+++ b/arch/metag/lib/umoddi3.S
@@ -0,0 +1,367 @@
+ .text
+ .global ___umoddi3
+ .type ___umoddi3,function
+ .align 2
+___umoddi3:
+ MSETL [A0StP++],D0FrT,D0.5,D0.6,D0.7
+ SETL [A0StP++],A0FrP,A1LbP
+ ADDT A1LbP,CPC1,#0
+ ADD A1LbP,A1LbP,#0
+ ADD A0StP,A0StP,#0x20
+ MOV D0.5,D0Ar4
+ ADDS D1.5,D1Ar3,#0
+ MOV D0Ar4,#0
+ MOV D1Ar3,#0
+ SETL [A0StP+#-8],D0Ar4,D1Ar3
+ MOV D0.6,D0.5
+ MOV D1.7,D0Ar2
+ MOV D1.6,D1Ar1
+ BNE $2a8
+ CMP D0.5,D1Ar1
+ BLS $c0
+ CMP D0.5,#0xffff
+ BHI $58
+ CMP D0.5,#0xff
+ MOV D1Ar3,#0x8
+ MOVLS D1Ar3,D1.5
+ B $68
+$58:
+ CMPMT D0.5,#0xff
+ MOV D0FrT,#0x10
+ ADDHI D0FrT,D0FrT,#0x8
+ MOV D1Ar3,D0FrT
+$68:
+ MOV D0Ar2,D1Ar3
+ GETD D0Ar4,[A1LbP]
+ LSR D0FrT,D0.6,D0Ar2
+ MOV D0Ar2,#0x20
+ GETB D0FrT,[D0FrT+D0Ar4]
+ SUB D0Ar4,D0Ar2,D1Ar3
+ SUBS D0.7,D0Ar4,D0FrT
+ MOVNE D0Ar4,D1.7
+ SUBNE D0FrT,D0Ar2,D0.7
+ MOVNE D0Ar2,D1.6
+ LSRNE D0FrT,D0Ar4,D0FrT
+ MOVNE D1Ar1,D0.7
+ LSLNE D0Ar4,D0Ar2,D0.7
+ ORNE D1.6,D0FrT,D0Ar4
+ LSLNE D0.6,D0.6,D0.7
+ LSLNE D1.7,D1.7,D1Ar1
+ LSR D1.5,D0.6,#0x10
+ MOV D1Ar1,D1.6
+ MOV D0Ar2,D1.5
+ CALLR D1RtP,___udivsi3
+ MOV D1Ar1,D1.6
+ B $208
+$c0:
+ CMP D0.5,#0
+ BNE $d8
+ MOV D1Ar1,#0x1
+ MOV D0Ar2,D0.5
+ CALLR D1RtP,___udivsi3
+ MOV D0.6,D0Re0
+$d8:
+ CMP D0.6,#0xffff
+ BHI $f0
+ CMP D0.6,#0xff
+ MOV D1Ar3,#0x8
+ MOVLS D1Ar3,D1.5
+ B $100
+$f0:
+ CMPMT D0.6,#0xff
+ MOV D0FrT,#0x10
+ ADDHI D0FrT,D0FrT,#0x8
+ MOV D1Ar3,D0FrT
+$100:
+ MOV D0Ar4,D1Ar3
+ MOV D0Ar2,#0x20
+ LSR D0FrT,D0.6,D0Ar4
+ GETD D0Ar4,[A1LbP]
+ GETB D0FrT,[D0FrT+D0Ar4]
+ SUB D0Ar4,D0Ar2,D1Ar3
+ SUBS D0.7,D0Ar4,D0FrT
+ SUBEQ D0.5,D1.6,D0.6
+ BEQ $1f4
+ SUB D0FrT,D0Ar2,D0.7
+ LSL D0.6,D0.6,D0.7
+ MOV D0Ar2,D1.6
+ LSR D1.5,D0.6,#0x10
+ MOV D0Ar4,D1.7
+ LSR D0.5,D0Ar2,D0FrT
+ MOV D1Ar1,D0.5
+ LSR D0FrT,D0Ar4,D0FrT
+ MOV D1.6,D0.6
+ LSL D0Ar4,D0Ar2,D0.7
+ MOV D0Ar2,D1.5
+ OR D0FrT,D0FrT,D0Ar4
+ SETD [A0StP+#-20],D0FrT
+ AND D1.6,D1.6,#0xffff
+ CALLR D1RtP,___udivsi3
+ MOV D1Ar1,D0.5
+ MOV D0Ar2,D1.5
+ MULD D0.5,D0Re0,D1.6
+ CALLR D1RtP,___umodsi3
+ GETD D0Ar2,[A0StP+#-20]
+ LSL D0Re0,D0Re0,#0x10
+ LSR D0FrT,D0Ar2,#0x10
+ OR D0FrT,D0FrT,D0Re0
+ CMP D0FrT,D0.5
+ BCC $19c
+ ADD D0FrT,D0FrT,D0.6
+ CMP D0FrT,D0.6
+ BCS $19c
+ CMP D0FrT,D0.5
+ ADDCS D0FrT,D0FrT,D0.6
+$19c:
+ SUB D0.5,D0FrT,D0.5
+ MOV D1Ar1,D0.5
+ MOV D0Ar2,D1.5
+ CALLR D1RtP,___udivsi3
+ MOV D1Ar1,D0.5
+ MOV D0Ar2,D1.5
+ MULD D0.5,D0Re0,D1.6
+ CALLR D1RtP,___umodsi3
+ GETD D0FrT,[A0StP+#-20]
+ LSL D0Re0,D0Re0,#0x10
+ AND D0FrT,D0FrT,#0xffff
+ OR D0Re0,D0Re0,D0FrT
+ CMP D0Re0,D0.5
+ BCC $1e8
+ ADD D0Re0,D0Re0,D0.6
+ CMP D0Re0,D0.6
+ BCS $1e8
+ CMP D0Re0,D0.5
+ ADDCS D0Re0,D0Re0,D0.6
+$1e8:
+ MOV D1Ar1,D0.7
+ SUB D0.5,D0Re0,D0.5
+ LSL D1.7,D1.7,D1Ar1
+$1f4:
+ LSR D1.5,D0.6,#0x10
+ MOV D1Ar1,D0.5
+ MOV D0Ar2,D1.5
+ CALLR D1RtP,___udivsi3
+ MOV D1Ar1,D0.5
+$208:
+ MOV D1.6,D0.6
+ MOV D0Ar2,D1.5
+ AND D1.6,D1.6,#0xffff
+ MULD D0.5,D0Re0,D1.6
+ CALLR D1RtP,___umodsi3
+ LSR D0FrT,D1.7,#0x10
+ LSL D0Re0,D0Re0,#0x10
+ OR D0Re0,D0Re0,D0FrT
+ CMP D0Re0,D0.5
+ BCC $244
+ ADD D0Re0,D0Re0,D0.6
+ CMP D0Re0,D0.6
+ BCS $244
+ CMP D0Re0,D0.5
+ ADDCS D0Re0,D0Re0,D0.6
+$244:
+ SUB D0.5,D0Re0,D0.5
+ MOV D1Ar1,D0.5
+ MOV D0Ar2,D1.5
+ CALLR D1RtP,___udivsi3
+ MOV D1Ar1,D0.5
+ MOV D0Ar2,D1.5
+ MULD D0.5,D0Re0,D1.6
+ CALLR D1RtP,___umodsi3
+ MOV D0FrT,D1.7
+ LSL D0Re0,D0Re0,#0x10
+ AND D0FrT,D0FrT,#0xffff
+ OR D0Re0,D0Re0,D0FrT
+ CMP D0Re0,D0.5
+ BCC $290
+ ADD D0Re0,D0Re0,D0.6
+ CMP D0Re0,D0.6
+ BCS $290
+ CMP D0Re0,D0.5
+ ADDCS D0Re0,D0Re0,D0.6
+$290:
+ SUB D0Re0,D0Re0,D0.5
+ LSR D0Re0,D0Re0,D0.7
+ MOV D0FrT,#0
+ SETD [A0StP+#-8],D0Re0
+ SETD [A0StP+#-4],D0FrT
+ B $51c
+$2a8:
+ MOV D0.5,D1.5
+ CMP D0.5,D1Ar1
+ BLS $2c0
+ SETD [A0StP+#-8],D0Ar2
+ SETD [A0StP+#-4],D1Ar1
+ B $51c
+$2c0:
+ CMP D1.5,#0xffff
+ BHI $2d4
+ CMP D1.5,#0xff
+ MOV D0FrT,#0
+ B $2dc
+$2d4:
+ CMPMT D1.5,#0xff
+ MOV D0FrT,#0x10
+$2dc:
+ GETD D0Ar4,[A1LbP]
+ ADDHI D0FrT,D0FrT,#0x8
+ MOV D1Ar3,D0FrT
+ LSR D0FrT,D0.5,D0FrT
+ GETB D0FrT,[D0FrT+D0Ar4]
+ MOV D0Ar2,#0x20
+ SUB D0Ar4,D0Ar2,D1Ar3
+ SUBS D0Ar4,D0Ar4,D0FrT
+ SETD [A0StP+#-32],D0Ar4
+ BNE $33c
+ CMP D1.6,D0.5
+ BHI $314
+ CMP D1.7,D0.6
+ BCS $330
+$314:
+ SUB D1Ar3,D1.7,D0.6
+ CMP D1Ar3,D1.7
+ SUB D0Ar4,D1.6,D0.5
+ MOV D0FrT,#0
+ ADDHI D0FrT,D0FrT,#0x1
+ SUB D1.6,D0Ar4,D0FrT
+ MOV D1.7,D1Ar3
+$330:
+ SETD [A0StP+#-8],D1.7
+ SETD [A0StP+#-4],D1.6
+ B $51c
+$33c:
+ GETD D1Ar3,[A0StP+#-32]
+ SUB D0Ar2,D0Ar2,D1Ar3
+ SETD [A0StP+#-28],D0Ar2
+ MOV D0Ar2,D1Ar3
+ LSL D0Ar4,D0.5,D0Ar2
+ GETD D0Ar2,[A0StP+#-28]
+ LSR D0FrT,D0.6,D0Ar2
+ OR D0.7,D0FrT,D0Ar4
+ MOV D1Ar1,D0Ar2
+ LSL D0Ar4,D1.6,D1Ar3
+ GETD D1Ar3,[A0StP+#-28]
+ LSR D0.5,D1.6,D1Ar1
+ LSR D0FrT,D0.7,#0x10
+ MOV D0Ar2,D0FrT
+ SETD [A0StP+#-16],D0FrT
+ LSR D0FrT,D1.7,D1Ar3
+ MOV D1Ar1,D0.5
+ OR D0FrT,D0FrT,D0Ar4
+ SETD [A0StP+#-24],D0FrT
+ CALLR D1RtP,___udivsi3
+ GETD D0Ar2,[A0StP+#-16]
+ MOV D1Ar1,D0.5
+ MOV D1.6,D0Re0
+ CALLR D1RtP,___umodsi3
+ MOV D0Ar2,D0.7
+ AND D0Ar2,D0Ar2,#0xffff
+ GETD D0Ar4,[A0StP+#-24]
+ MULD D0.5,D0Ar2,D1.6
+ SETD [A0StP+#-12],D0Ar2
+ GETD D0Ar2,[A0StP+#-32]
+ LSL D0Re0,D0Re0,#0x10
+ LSR D0FrT,D0Ar4,#0x10
+ OR D0Re0,D0Re0,D0FrT
+ MOV D1Ar1,D0Ar2
+ CMP D0Re0,D0.5
+ LSL D0.6,D0.6,D0Ar2
+ LSL D1.7,D1.7,D1Ar1
+ BCC $3f0
+ ADD D0Re0,D0Re0,D0.7
+ CMP D0Re0,D0.7
+ SUB D1.6,D1.6,#0x1
+ BCS $3f0
+ CMP D0Re0,D0.5
+ SUBCS D1.6,D1.6,#0x1
+ ADDCS D0Re0,D0Re0,D0.7
+$3f0:
+ SUB D0.5,D0Re0,D0.5
+ GETD D0Ar2,[A0StP+#-16]
+ MOV D1Ar1,D0.5
+ CALLR D1RtP,___udivsi3
+ GETD D0Ar2,[A0StP+#-16]
+ MOV D1Ar1,D0.5
+ MOV D1.5,D0Re0
+ CALLR D1RtP,___umodsi3
+ GETD D0FrT,[A0StP+#-24]
+ GETD D1Ar3,[A0StP+#-12]
+ LSL D0Re0,D0Re0,#0x10
+ AND D0FrT,D0FrT,#0xffff
+ MULD D1Re0,D1Ar3,D1.5
+ OR D1Ar5,D0Re0,D0FrT
+ CMP D1Ar5,D1Re0
+ BCC $44c
+ ADD D1Ar5,D1Ar5,D0.7
+ SUB D1.5,D1.5,#0x1
+ CMP D1Ar5,D0.7
+ BCS $44c
+ CMP D1Ar5,D1Re0
+ SUBCS D1.5,D1.5,#0x1
+ ADDCS D1Ar5,D1Ar5,D0.7
+$44c:
+ LSL D0FrT,D1.6,#0x10
+ MOV D1Ar3,D0.6
+ LSR D0Ar2,D0.6,#0x10
+ OR D0FrT,D1.5,D0FrT
+ AND D1Ar3,D1Ar3,#0xffff
+ LSR D1Ar1,D0FrT,#0x10
+ AND D0FrT,D0FrT,#0xffff
+ MULD D0Ar6,D1Ar1,D1Ar3
+ MULD D1Ar3,D0FrT,D1Ar3
+ MULD D0Ar4,D0FrT,D0Ar2
+ LSR D0FrT,D1Ar3,#0x10
+ ADD D0Ar4,D0Ar6,D0Ar4
+ ADD D0Ar4,D0Ar4,D0FrT
+ CMP D0Ar4,D0Ar6
+ MULD D1Ar1,D1Ar1,D0Ar2
+ SUB D0.5,D1Ar5,D1Re0
+ BCC $494
+ ADDT D1Ar1,D1Ar1,#0x1
+$494:
+ LSR D0FrT,D0Ar4,#0x10
+ ADD D0Ar2,D1Ar1,D0FrT
+ MOV D0FrT,D1Ar3
+ LSL D0Ar4,D0Ar4,#0x10
+ AND D0FrT,D0FrT,#0xffff
+ CMP D0Ar2,D0.5
+ ADD D0Re0,D0Ar4,D0FrT
+ BHI $4c4
+ CMP D0Ar2,D0.5
+ BNE $4e0
+ CMP D0Re0,D1.7
+ BLS $4e0
+$4c4:
+ SUB D1Ar3,D0Re0,D0.6
+ MOV D0FrT,#0
+ SUB D0Ar4,D0Ar2,D0.7
+ CMP D1Ar3,D0Re0
+ ADDHI D0FrT,D0FrT,#0x1
+ MOV D0Re0,D1Ar3
+ SUB D0Ar2,D0Ar4,D0FrT
+$4e0:
+ SUB D0Ar4,D1.7,D0Re0
+ SUB D1Ar3,D0.5,D0Ar2
+ GETD D1Ar1,[A0StP+#-28]
+ CMP D0Ar4,D1.7
+ GETD D0Ar2,[A0StP+#-32]
+ MOV D0FrT,#0
+ ADDHI D0FrT,D0FrT,#0x1
+ SUB D1Ar3,D1Ar3,D0FrT
+ LSL D0FrT,D1Ar3,D1Ar1
+ MOV D1Ar1,D0Ar2
+ LSR D0Ar4,D0Ar4,D0Ar2
+ OR D0FrT,D0FrT,D0Ar4
+ LSR D1Ar3,D1Ar3,D1Ar1
+ SETD [A0StP+#-8],D0FrT
+ SETD [A0StP+#-4],D1Ar3
+$51c:
+ GETL D0Re0,D1Re0,[A0StP+#-8]
+ GETL D0FrT,D1RtP,[A0StP+#-72]
+ GETL D0.5,D1.5,[A0StP+#-64]
+ GETL D0.6,D1.6,[A0StP+#-56]
+ GETL D0.7,D1.7,[A0StP+#-48]
+ GETL A0FrP,A1LbP,[A0StP+#-40]
+ SUB A0StP,A0StP,#0x48
+ MOV PC,D1RtP
+ .size ___umoddi3,.-___umoddi3
+
--
1.7.11.7
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] arch: metag: lib: add "umoddi3.S" file for __umoddi3()
2013-12-19 12:05 [PATCH] arch: metag: lib: add "umoddi3.S" file for __umoddi3() Chen Gang
@ 2013-12-19 12:17 ` James Hogan
2013-12-19 13:37 ` Chen Gang
0 siblings, 1 reply; 9+ messages in thread
From: James Hogan @ 2013-12-19 12:17 UTC (permalink / raw)
To: Chen Gang; +Cc: rostedt, linux-kernel@vger.kernel.org, linux-metag
On 19/12/13 12:05, Chen Gang wrote:
> Use objdump to get "umoddi3.S" for __umoddi3(), the original binary
> file is "gcc-4.2.4-final/gcc/libgcc/umoddi3.o" which is generated by
> "gcc-4.2.4/gcc/libgcc2.c".
>
> The relate error with allmodconfig:
>
> MODPOST 2909 modules
> ERROR: "__umoddi3" [drivers/target/target_core_mod.ko] undefined!
_umoddi3 is a 64bit division, which should be using the proper division
functions provided by the kernel in <linux/math64.h>.
It needs fixing wherever it comes from in drivers/target/target_core_mod.ko.
Cheers
James
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] arch: metag: lib: add "umoddi3.S" file for __umoddi3()
2013-12-19 12:17 ` James Hogan
@ 2013-12-19 13:37 ` Chen Gang
2013-12-19 13:47 ` James Hogan
0 siblings, 1 reply; 9+ messages in thread
From: Chen Gang @ 2013-12-19 13:37 UTC (permalink / raw)
To: James Hogan; +Cc: rostedt, linux-kernel@vger.kernel.org, linux-metag
On 12/19/2013 08:17 PM, James Hogan wrote:
> On 19/12/13 12:05, Chen Gang wrote:
>> Use objdump to get "umoddi3.S" for __umoddi3(), the original binary
>> file is "gcc-4.2.4-final/gcc/libgcc/umoddi3.o" which is generated by
>> "gcc-4.2.4/gcc/libgcc2.c".
>>
>> The relate error with allmodconfig:
>>
>> MODPOST 2909 modules
>> ERROR: "__umoddi3" [drivers/target/target_core_mod.ko] undefined!
>
> _umoddi3 is a 64bit division, which should be using the proper division
> functions provided by the kernel in <linux/math64.h>.
>
> It needs fixing wherever it comes from in drivers/target/target_core_mod.ko.
>
After disassemble target_core_mod.ko, for me, the compiler will use
___umoddi3 for '%' operator and use ___udivsi3 for '/' operator.
If what I guess is correct, we need use/copy the "system library" which
compiler provides, so just use its ".o" file is OK (just like another
"arch/metag/lib/*.S" have done).
The related C code is below:
463 static inline int core_alua_state_lba_dependent(
464 struct se_cmd *cmd,
465 struct t10_alua_tg_pt_gp *tg_pt_gp,
466 u8 *alua_ascq)
467 {
468 struct se_device *dev = cmd->se_dev;
469 u32 segment_size, segment_mult, sectors;
470 u64 lba;
471
472 /* Only need to check for cdb actually containing LBAs */
473 if (!cmd->se_cmd_flags & SCF_SCSI_DATA_CDB)
474 return 0;
475
476 spin_lock(&dev->t10_alua.lba_map_lock);
477 segment_size = dev->t10_alua.lba_map_segment_size;
478 segment_mult = dev->t10_alua.lba_map_segment_multiplier;
479 sectors = cmd->data_length / dev->dev_attrib.block_size; /* use ___udivsi3 */
480
481 lba = cmd->t_task_lba;
482 while (lba < cmd->t_task_lba + sectors) {
483 struct t10_alua_lba_map *cur_map = NULL, *map;
484 struct t10_alua_lba_map_member *map_mem;
485
486 list_for_each_entry(map, &dev->t10_alua.lba_map_list,
487 lba_map_list) {
488 u64 start_lba, last_lba;
489 u64 first_lba = map->lba_map_first_lba;
490
491 if (segment_mult) {
492 start_lba = lba % (segment_size * segment_mult); /* use ___umoddi3 */
493 last_lba = first_lba + segment_size - 1;
494 if (start_lba >= first_lba &&
495 start_lba <= last_lba) {
...
The related disassemble code is below:
280: ed 06 18 a7 GETD D0Ar2,[A0FrP+#52]
284: 24 d5 38 c6 GETD D1.7,[D0Ar2+#84]
288: 04 0e 18 01 MOV D1Ar1,D1.7
28c: 20 1c 18 03 ADD D1Ar1,D1Ar1,#0x384
290: f5 05 18 a5 SETD [A0FrP+#44],D1Ar1
294: 14 00 00 ab CALLR D1RtP,294 <__raw_spin_lock+0x294>
298: ed 06 20 a7 GETD D0FrT,[A0FrP+#52]
29c: 05 1e 08 00 MOV D0Ar6,D1.7
2a0: 24 0a 19 c6 GETD D1Ar1,[D0FrT+#40]
2a4: ad 9c 18 a7 GETD D0Ar2,[D0Ar6+#1252]
2a8: 35 76 08 a7 GETD D1Ar5,[D0Ar6+#944]
2ac: ad 75 28 a7 GETD D0.5,[D0Ar6+#940]
2b0: 75 05 08 a5 SETD [A0FrP+#40],D1Ar5
2b4: 14 00 00 ab CALLR D1RtP,2b4 <___udivsi3+0x2b4>
2b8: ed 06 10 a7 GETD D0Ar4,[A0FrP+#52]
2bc: 6d 05 18 a7 GETD D0Ar2,[A0FrP+#40]
2c0: 04 00 00 03 MOV D1Re0,#0
2c4: 22 9c 30 c7 GETL D0.6,D1.6,[D0Ar4+#224]
2c8: 40 ca 20 60 MULD D0FrT,D0Ar2,D0.5
2cc: 00 0c 00 08 ADDS D0Re0,D0Re0,D0.6
2d0: 04 0e 18 01 MOV D1Ar1,D1.7
2d4: 00 0c 00 01 ADD D1Re0,D1Re0,D1.6
2d8: a0 1d 18 03 ADD D1Ar1,D1Ar1,#0x3b4
2dc: 46 00 00 07 ADDCS D1Re0,D1Re0,#0x1
2e0: 04 08 08 00 MOV D0Ar6,D0FrT
2e4: 04 00 08 03 MOV D1Ar5,#0
2e8: 04 0a 10 00 MOV D0Ar4,D0.5
2ec: 04 00 10 03 MOV D1Ar3,#0
2f0: 75 08 18 a5 SETD [A0FrP+#64],D1Ar1
2f4: ef 03 00 a5 SETL [A0FrP+#56],D0Re0,D1Re0
2f8: 6f 02 08 a5 SETL [A0FrP+#32],D0Ar6,D1Ar5
2fc: ef 04 10 a5 SETL [A0FrP+#72],D0Ar4,D1Ar3
300: 40 0b 00 a0 B 468 <_target_alua_state_check+0x468>
304: 05 1e 08 00 MOV D0Ar6,D1.7
308: ad 76 20 a7 GETD D0FrT,[D0Ar6+#948]
30c: a0 06 00 a0 B 3e0 <_target_alua_state_check+0x3e0>
310: 75 05 08 a7 GETD D1Ar5,[A0FrP+#40]
314: 22 c0 29 c7 GETL D0.5,D1.5,[D0.7]
318: 00 00 08 73 CMP D1Ar5,#0
31c: c2 03 00 a0 BEQ 394 <_target_alua_state_check+0x394>
320: 6f 02 10 a7 GETL D0Ar4,D1Ar3,[A0FrP+#32]
324: 04 0c 18 00 MOV D0Ar2,D0.6
328: 04 0c 18 01 MOV D1Ar1,D1.6
32c: 14 00 00 ab CALLR D1RtP,32c <___umoddi3+0x32c>
330: 00 40 01 71 CMP D1.5,D1Re0
334: 52 05 00 a0 BHI 3dc <_target_alua_state_check+0x3dc>
338: 00 40 01 71 CMP D1.5,D1Re0
33c: 64 00 00 a0 BNE 348 <_target_alua_state_check+0x348>
340: 00 40 01 70 CMP D0.5,D0Re0
344: d2 04 00 a0 BHI 3dc <_target_alua_state_check+0x3dc>
348: ef 04 08 a7 GETL D0Ar6,D1Ar5,[A0FrP+#72]
34c: fe ff 1f 02 MOV D0Ar2,#-1
350: fe ff 1f 03 MOV D1Ar1,#-1
...
Thanks.
--
Chen Gang
Open, share and attitude like air, water and life which God blessed
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] arch: metag: lib: add "umoddi3.S" file for __umoddi3()
2013-12-19 13:37 ` Chen Gang
@ 2013-12-19 13:47 ` James Hogan
2013-12-20 1:44 ` Chen Gang
0 siblings, 1 reply; 9+ messages in thread
From: James Hogan @ 2013-12-19 13:47 UTC (permalink / raw)
To: Chen Gang; +Cc: rostedt, linux-kernel@vger.kernel.org, linux-metag
On 19/12/13 13:37, Chen Gang wrote:
> On 12/19/2013 08:17 PM, James Hogan wrote:
>> On 19/12/13 12:05, Chen Gang wrote:
>>> Use objdump to get "umoddi3.S" for __umoddi3(), the original binary
>>> file is "gcc-4.2.4-final/gcc/libgcc/umoddi3.o" which is generated by
>>> "gcc-4.2.4/gcc/libgcc2.c".
>>>
>>> The relate error with allmodconfig:
>>>
>>> MODPOST 2909 modules
>>> ERROR: "__umoddi3" [drivers/target/target_core_mod.ko] undefined!
>>
>> _umoddi3 is a 64bit division, which should be using the proper division
>> functions provided by the kernel in <linux/math64.h>.
>>
>> It needs fixing wherever it comes from in drivers/target/target_core_mod.ko.
>>
>
> After disassemble target_core_mod.ko, for me, the compiler will use
> ___umoddi3 for '%' operator and use ___udivsi3 for '/' operator.
Yeh, % is in this case remainder from a 64bit division, for which the
standard division functions in <linux/math64.h> should be used instead.
> If what I guess is correct, we need use/copy the "system library" which
> compiler provides, so just use its ".o" file is OK (just like another
> "arch/metag/lib/*.S" have done).
No, I believe there shouldn't be any use of the C 64bit division/modulo
operations in generic kernel code in the first place, so like I said
before the code in question should be fixed to use the proper functions
in <linux/math64.h>.
Cheers
James
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] arch: metag: lib: add "umoddi3.S" file for __umoddi3()
2013-12-19 13:47 ` James Hogan
@ 2013-12-20 1:44 ` Chen Gang
2013-12-20 9:30 ` James Hogan
0 siblings, 1 reply; 9+ messages in thread
From: Chen Gang @ 2013-12-20 1:44 UTC (permalink / raw)
To: James Hogan; +Cc: Chen Gang, rostedt, linux-kernel@vger.kernel.org, linux-metag
On 12/19/2013 09:47 PM, James Hogan wrote:
> On 19/12/13 13:37, Chen Gang wrote:
>> On 12/19/2013 08:17 PM, James Hogan wrote:
>>> On 19/12/13 12:05, Chen Gang wrote:
>>>> Use objdump to get "umoddi3.S" for __umoddi3(), the original binary
>>>> file is "gcc-4.2.4-final/gcc/libgcc/umoddi3.o" which is generated by
>>>> "gcc-4.2.4/gcc/libgcc2.c".
>>>>
>>>> The relate error with allmodconfig:
>>>>
>>>> MODPOST 2909 modules
>>>> ERROR: "__umoddi3" [drivers/target/target_core_mod.ko] undefined!
>>>
>>> _umoddi3 is a 64bit division, which should be using the proper division
>>> functions provided by the kernel in <linux/math64.h>.
>>>
>>> It needs fixing wherever it comes from in drivers/target/target_core_mod.ko.
>>>
>>
>> After disassemble target_core_mod.ko, for me, the compiler will use
>> ___umoddi3 for '%' operator and use ___udivsi3 for '/' operator.
>
> Yeh, % is in this case remainder from a 64bit division, for which the
> standard division functions in <linux/math64.h> should be used instead.
>
>> If what I guess is correct, we need use/copy the "system library" which
>> compiler provides, so just use its ".o" file is OK (just like another
>> "arch/metag/lib/*.S" have done).
>
> No, I believe there shouldn't be any use of the C 64bit division/modulo
> operations in generic kernel code in the first place, so like I said
> before the code in question should be fixed to use the proper functions
> in <linux/math64.h>.
>
OK, thanks, your idea is one of fix ways.
Hmm... for me, it is still not a bad idea to add "__umoddi3" to metag.
- there are already several 64-bit functions in "arch/metag/lib/*.S".
- some of architectures already content "__umoddi3".
- it is easier for users (e.g. various drivers) to use '%' and '/'.
(especially, we have already support '/').
Thanks
> Cheers
> James
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Chen Gang
Open, share and attitude like air, water and life which God blessed
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] arch: metag: lib: add "umoddi3.S" file for __umoddi3()
2013-12-20 1:44 ` Chen Gang
@ 2013-12-20 9:30 ` James Hogan
2013-12-20 10:20 ` Chen Gang
0 siblings, 1 reply; 9+ messages in thread
From: James Hogan @ 2013-12-20 9:30 UTC (permalink / raw)
To: Chen Gang; +Cc: rostedt, linux-kernel@vger.kernel.org, linux-metag
On 20/12/13 01:44, Chen Gang wrote:
> On 12/19/2013 09:47 PM, James Hogan wrote:
>> No, I believe there shouldn't be any use of the C 64bit division/modulo
>> operations in generic kernel code in the first place, so like I said
>> before the code in question should be fixed to use the proper functions
>> in <linux/math64.h>.
>>
>
> OK, thanks, your idea is one of fix ways.
>
> Hmm... for me, it is still not a bad idea to add "__umoddi3" to metag.
NAK
Please read this:
http://yarchive.net/comp/linux/64bit_divide.html
Cheers
James
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] arch: metag: lib: add "umoddi3.S" file for __umoddi3()
2013-12-20 9:30 ` James Hogan
@ 2013-12-20 10:20 ` Chen Gang
2013-12-20 10:48 ` James Hogan
0 siblings, 1 reply; 9+ messages in thread
From: Chen Gang @ 2013-12-20 10:20 UTC (permalink / raw)
To: James Hogan; +Cc: rostedt, linux-kernel@vger.kernel.org, linux-metag
On 12/20/2013 05:30 PM, James Hogan wrote:
> On 20/12/13 01:44, Chen Gang wrote:
>> On 12/19/2013 09:47 PM, James Hogan wrote:
>>> No, I believe there shouldn't be any use of the C 64bit division/modulo
>>> operations in generic kernel code in the first place, so like I said
>>> before the code in question should be fixed to use the proper functions
>>> in <linux/math64.h>.
>>>
>>
>> OK, thanks, your idea is one of fix ways.
>>
>> Hmm... for me, it is still not a bad idea to add "__umoddi3" to metag.
>
> NAK
>
> Please read this:
> http://yarchive.net/comp/linux/64bit_divide.html
>
OK, thanks, that sounds reasonable to me. For kernel, we really need
treat it carefully.
Hmm... but do you know why we need some 64-bit functions which are
implemented under "arch/metag/lib/*.S"? can we use <linux/math64.h>
instead of them? (e.g 64-bit '/').
And for me, 64-bit '/' and '%' are related operations, if provide one,
we also need provide the other (or neither of them are provided).
Thanks.
--
Chen Gang
Open, share and attitude like air, water and life which God blessed
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] arch: metag: lib: add "umoddi3.S" file for __umoddi3()
2013-12-20 10:20 ` Chen Gang
@ 2013-12-20 10:48 ` James Hogan
2013-12-20 11:51 ` Chen Gang
0 siblings, 1 reply; 9+ messages in thread
From: James Hogan @ 2013-12-20 10:48 UTC (permalink / raw)
To: Chen Gang; +Cc: rostedt, linux-kernel@vger.kernel.org, linux-metag
On 20/12/13 10:20, Chen Gang wrote:
> Hmm... but do you know why we need some 64-bit functions which are
> implemented under "arch/metag/lib/*.S"? can we use <linux/math64.h>
> instead of them? (e.g 64-bit '/').
If you look at linux/math64.h you'll see it only implements division
operations. The other 64 bit operations like shift, compare, and
multiply are relatively cheap so are implemented as intrinsics instead.
Cheers
James
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] arch: metag: lib: add "umoddi3.S" file for __umoddi3()
2013-12-20 10:48 ` James Hogan
@ 2013-12-20 11:51 ` Chen Gang
0 siblings, 0 replies; 9+ messages in thread
From: Chen Gang @ 2013-12-20 11:51 UTC (permalink / raw)
To: James Hogan; +Cc: rostedt, linux-kernel@vger.kernel.org, linux-metag
On 12/20/2013 06:48 PM, James Hogan wrote:
> On 20/12/13 10:20, Chen Gang wrote:
>> Hmm... but do you know why we need some 64-bit functions which are
>> implemented under "arch/metag/lib/*.S"? can we use <linux/math64.h>
>> instead of them? (e.g 64-bit '/').
>
> If you look at linux/math64.h you'll see it only implements division
> operations. The other 64 bit operations like shift, compare, and
> multiply are relatively cheap so are implemented as intrinsics instead.
>
OK, thanks. tomorrow, I will send related patch: use 'div64_u64_rem'
instead of umoddi3 ('%'). :-)
And I guess, in kernel wide, we need remove all 'umoddi3' and 'udivdi3'.
umoddi3 ('%'): frv, ia64, parisc, tile, xtensa
udivdi3 ('/'): frv, ia64, parisc, tile, xtensa, sh, sparc.
especially, sh and sparc only provide '/', do not provide '%'.
BTW: originally, I make a mistake -- treat 'udevsi3' as 'udevdi3'.
Thanks.
--
Chen Gang
Open, share and attitude like air, water and life which God blessed
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-12-20 11:51 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-19 12:05 [PATCH] arch: metag: lib: add "umoddi3.S" file for __umoddi3() Chen Gang
2013-12-19 12:17 ` James Hogan
2013-12-19 13:37 ` Chen Gang
2013-12-19 13:47 ` James Hogan
2013-12-20 1:44 ` Chen Gang
2013-12-20 9:30 ` James Hogan
2013-12-20 10:20 ` Chen Gang
2013-12-20 10:48 ` James Hogan
2013-12-20 11:51 ` Chen Gang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox