From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Daney Subject: Re: [PATCH v3 0/2] Stop some of the abuse of BUG() where compile time checks should be used. Date: Mon, 28 Nov 2011 09:03:20 -0800 Message-ID: <4ED3BED8.4000000@caviumnetworks.com> References: <1322092017-21471-1-git-send-email-ddaney.cavm@gmail.com> <4ECD91E4.5090504@gmail.com> <20469.1322130295@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail3.caviumnetworks.com ([12.108.191.235]:5127 "EHLO mail3.caviumnetworks.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750878Ab1K1RDV (ORCPT ); Mon, 28 Nov 2011 12:03:21 -0500 In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Linus Torvalds Cc: David Howells , David Daney , Andrew Morton , "ralf@linux-mips.org" , "linux-kernel@vger.kernel.org" , "linux-arch@vger.kernel.org" , David Rientjes , DM , David Daney , "Pinski, Andrew" On 11/24/2011 10:31 AM, Linus Torvalds wrote: > On Thu, Nov 24, 2011 at 2:24 AM, David Howells wrote: >> >> Have you tried asking the gcc folks if this is likely to get fixed soon? > > I actually don't think it's a bug. The error message is associated > with the function declaration symbol, so it actually makes sense that > there can be only one error message per callee - not per caller. > Yes, that is correct. > Using "__LINE__" to then create fairly unique symbols (modulo > #include, of course) gets around it in a pretty natural way as ddaney > said, so if we care enough. I don't think it's a big issue (as > mentioned, I'd worry more about us making sure it's reliable enough to > be used - we've had gcc sometimes fail to compile things out just > because some optimization was not working well enough). > Since these are *build* bugs, they are of a different nature than the *runtime* variety. They will never be seen at random times by someone running the kernel, so making it easier to determine their cause is less important. Really, I would expect it to never really be an issue. We will always know which file is the culprit. Finding the line number can be done like this: objdump -r $file | grep build_bug | addr2line -e $file David Daney