From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S932170AbXALQbx@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932170AbXALQbx (ORCPT <rfc822;w@1wt.eu>);
	Fri, 12 Jan 2007 11:31:53 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932210AbXALQbx
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 12 Jan 2007 11:31:53 -0500
Received: from smtp110.sbc.mail.mud.yahoo.com ([68.142.198.209]:34254 "HELO
	smtp110.sbc.mail.mud.yahoo.com" rhost-flags-OK-OK-OK-OK)
	by vger.kernel.org with SMTP id S932170AbXALQbw (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 12 Jan 2007 11:31:52 -0500
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=pacbell.net;
  h=Received:X-YMail-OSG:From:To:Subject:Date:User-Agent:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id;
  b=td7sZPPtHKrLVyaygCOFJHWTK7zACTUOvLBuH1pz6WyR3S7OoBlZxGG9CyEAu/Cf4JHIaOKVhcgw+5ZDZWGQyMN1CYQMoG1bFLK7CcAXby7RqCFyDIvoWkAO2Ej5Jw+VhN2TbJbI+iple9wvd4ph1MRwJxhpPqt/UIZm+DqSRV0=  ;
X-YMail-OSG: OOR7JUYVM1kKylRv9wfJE1gJem.K94A9A22.roPp1TlE0B_thX7igO3mBXexw1Cw2u2zRc7STgP6xltdrdIijl7QFDbPZ2Fobz8ulfNpxA25AL9iFB5PgS7HIl6IkYWGvClQpby3eaWFsck-
From: David Brownell <david-b@pacbell.net>
To: Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: [patch 2.6.20-rc4-git] remove modpost false warnings on ARM
Date: Fri, 12 Jan 2007 08:31:36 -0800
User-Agent: KMail/1.7.1
Cc: rusty@rustcorp.com.au, Russell King <rmk@arm.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200701120831.37513.david-b@pacbell.net>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

This patch stops "modpost" from issuing erroneous modpost warnings on ARM
builds, which it's been doing simce since maybe last summer.  A canonical
example would be driver method table entries:

  WARNING: <path> - Section mismatch: reference to .exit.text:<name>_remove
	from .data after '$d' (at offset 0x4)

That "$d" symbol is generated by tools conformant with ARM ABI specs; in
this case, it's a relocation in the start of a "<name>_driver" struct.
The erroneous warnings appear to be issued because "modpost" whitelists
references from "<name>_driver" data into init and exit sections ... but
does NOT whitelist them from "$d" (and can't).

This patch prevents the modpost symbol lookup code from ever returning
those symbols, so it will return a whitelisted symbol instead.

Now to revert various code-bloating "fixes" that got merged because of
this modpost bug....

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

---
Likely this patch can be improved on, but there's another issue.
It seems to me that these modpost checks are wrong:

  * Lingering pointers that point into sections modprobe removes are
    *always* unsafe ... including probe() methods marked "__init"
    on hotpluggable busses.  Trivial fix:  use __devinit instead;
    or maybe platform_driver_probe().
  * Lingering pointers that point into sections that aren't removed
    are *never* unsafe ... including this remove() method case, since
    module unloading is configured and the __exit stuff must stay.

Whitelisting the former means not reporting potential oopsing cases;
dangerous.  Whereas even *checking* the latter is a waste of effort.


Index: at91/scripts/mod/modpost.c
===================================================================
--- at91.orig/scripts/mod/modpost.c	2007-01-11 22:51:49.000000000 -0800
+++ at91/scripts/mod/modpost.c	2007-01-12 04:20:00.000000000 -0800
@@ -679,6 +679,26 @@ static Elf_Sym *find_elf_symbol(struct e
 }
 
 /*
+ * If there's no name there, ignore it; likewise, ignore it if it's
+ * one of the magic symbols emitted used by current ARM tools.
+ *
+ * Otherwise if find_symbols_between() returns those symbols, they'll
+ * fail the whitelist tests and cause lots of false alarms ... fixable
+ * only by shrinking __exit and __init sections into __text, bloating
+ * the kernel (which is especially evil on embedded platforms).
+ */
+static int is_valid_name(struct elf_info *elf, Elf_Sym *sym)
+{
+	const char *name = elf->strtab + sym->st_name;
+
+	if (!name || !strlen(name))
+		return 0;
+	if (strcmp(name, "$a") == 0 || strcmp(name, "$d") == 0)
+		return 0;
+	return 1;
+}
+
+/*
  * Find symbols before or equal addr and after addr - in the section sec.
  * If we find two symbols with equal offset prefer one with a valid name.
  * The ELF format may have a better way to detect what type of symbol
@@ -706,16 +726,15 @@ static void find_symbols_between(struct 
 		symsec = secstrings + elf->sechdrs[sym->st_shndx].sh_name;
 		if (strcmp(symsec, sec) != 0)
 			continue;
+		if (!is_valid_name(elf, sym))
+			continue;
 		if (sym->st_value <= addr) {
 			if ((addr - sym->st_value) < beforediff) {
 				beforediff = addr - sym->st_value;
 				*before = sym;
 			}
 			else if ((addr - sym->st_value) == beforediff) {
-				/* equal offset, valid name? */
-				const char *name = elf->strtab + sym->st_name;
-				if (name && strlen(name))
-					*before = sym;
+				*before = sym;
 			}
 		}
 		else
@@ -725,10 +744,7 @@ static void find_symbols_between(struct 
 				*after = sym;
 			}
 			else if ((sym->st_value - addr) == afterdiff) {
-				/* equal offset, valid name? */
-				const char *name = elf->strtab + sym->st_name;
-				if (name && strlen(name))
-					*after = sym;
+				*after = sym;
 			}
 		}
 	}