From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754394Ab3LSNsj (ORCPT ); Thu, 19 Dec 2013 08:48:39 -0500 Received: from multi.imgtec.com ([194.200.65.239]:5824 "EHLO multi.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751027Ab3LSNsh (ORCPT ); Thu, 19 Dec 2013 08:48:37 -0500 Message-ID: <52B2F8DC.8060006@imgtec.com> Date: Thu, 19 Dec 2013 13:47:08 +0000 From: James Hogan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Chen Gang CC: , "linux-kernel@vger.kernel.org" , Subject: Re: [PATCH] arch: metag: lib: add "umoddi3.S" file for __umoddi3() References: <52B2E0FA.7090805@gmail.com> <52B2E3DB.7010008@imgtec.com> <52B2F6B7.1050802@gmail.com> In-Reply-To: <52B2F6B7.1050802@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.154.65] X-SEF-Processed: 7_3_0_01192__2013_12_19_13_48_30 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 . >> >> 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 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 . Cheers James