Date: 26 Jan 2006 05:28:48 +0100
Date: Thu, 26 Jan 2006 05:28:48 +0100
From: Andi Kleen <ak@muc.de>
To: Keith Owens <kaos@ocs.com.au>
Cc: Ashok Raj <ashok.raj@intel.com>, akpm@osdl.org,
       linux-kernel@vger.kernel.org, randy.d.dunlap@intel.com
Subject: Re: wrongly marked __init/__initdata for CPU hotplug
Message-ID: <20060126042848.GB88680@muc.de>
References: <20060125120253.A30999@unix-os.sc.intel.com> <4496.1138242917@ocs3.ocs.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4496.1138242917@ocs3.ocs.com.au>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1175
Lines: 29

> This is nasty.  init() calls do_basic_setup() which calls
> do_initcalls().  init is normal text.  do_basic_setup and do_initcalls
> are .init.text.  gcc has inlined do_basic_setup and do_initcalls into
> init, even though they have different section attributes.  Naughty gcc.
> 
> This was using GCC: (GNU) 4.0.2 20050901 (prerelease) (SUSE Linux).
> Log a gcc bug.  Not a good omen for the idea of letting gcc decide when
> to inline!

Someone should file a bug in the gcc bugzilla then I guess.
Can you do that or should I?

> 
> Looking at the C code for do_initcalls(), the reference is obviously to
> initcall_debug.  I am puzzled about why the objdump lists
> .init.data+0x15b when initcall_debug is really at .init.data+0x164.

Ah thanks - ok i mislooked then. Anyways, it's not a bug.
 
> BTW, does anybody know why init() is not defined as __init?

Because it would crash then after returning from free_initmem.

-Andi
-
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/