1. 17 7月, 2007 13 次提交
  2. 12 6月, 2007 1 次提交
    • S
      kbuild: fix sh64 section mismatch problems · 2648a53a
      Sam Ravnborg 提交于
      There's a special .cranges section that is almost always generated,
      with data being moved to the appropriate section by the linker at a later
      stage.
      
      To give a bit of background, sh64 has both a native SHmedia instruction
      set (32-bit instructions) and SHcompact (which is compatability with
      normal SH -- 16-bit, a massively reduced register set, etc.). code ranges
      are emitted when we're using the 32-bit ABI, but not the 64-bit one.
      
      It is a special staging section used solely by binutils where code with
      different flags get placed (more specifically differing flags for input
      and output sections), before being lazily merged by the linker.
      
      The closest I've been able to find to documentation is:
        http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/ld/emultempl/sh64elf.em?rev=1.10&content-type=text/x-cvsweb-markup&cvsroot=src
      
      It's an array of 8-byte Elf32_CRange structure given in
        http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/elf32-sh64.h?rev=1.4&content-type=text/x-cvsweb-markup&cvsroot=src
      that describes for which ISA a range is used.
      
      Silence the warnings by allowing references from .init.text to .cranges.
      
      The following warnings are fixed:
      
      WARNING: init/built-in.o(.cranges+0x0): Section mismatch: reference to .init.text:
      WARNING: init/built-in.o(.cranges+0xa): Section mismatch: reference to .init.text:
      WARNING: init/built-in.o(.cranges+0x14): Section mismatch: reference to .init.text:
      WARNING: init/built-in.o(.cranges+0x1e): Section mismatch: reference to .init.text:
      WARNING: init/built-in.o(.cranges+0x28): Section mismatch: reference to .init.text:
      WARNING: init/built-in.o(.cranges+0x32): Section mismatch: reference to .init.text:
      WARNING: kernel/built-in.o(.cranges+0x50): Section mismatch: reference to .init.text:
      WARNING: kernel/built-in.o(.cranges+0x5a): Section mismatch: reference to .init.text:
      WARNING: kernel/built-in.o(.cranges+0x64): Section mismatch: reference to .init.text:
      WARNING: kernel/built-in.o(.cranges+0xfa): Section mismatch: reference to .init.text:
      WARNING: kernel/built-in.o(.cranges+0x104): Section mismatch: reference to .init.text:
      WARNING: kernel/built-in.o(.cranges+0x10e): Section mismatch: reference to .init.text:
      WARNING: kernel/built-in.o(.cranges+0x14a): Section mismatch: reference to .init.text:
      WARNING: kernel/built-in.o(.cranges+0x154): Section mismatch: reference to .init.text:
      WARNING: kernel/built-in.o(.cranges+0x15e): Section mismatch: reference to .init.text:
      WARNING: mm/built-in.o(.cranges+0x6e): Section mismatch: reference to .init.text:
      WARNING: mm/built-in.o(.cranges+0x78): Section mismatch: reference to .init.text:
      WARNING: mm/built-in.o(.cranges+0x82): Section mismatch: reference to .init.text:
      WARNING: mm/built-in.o(.cranges+0xaa): Section mismatch: reference to .init.text:
      WARNING: fs/built-in.o(.cranges+0x136): Section mismatch: reference to .init.text:
      WARNING: fs/built-in.o(.cranges+0x140): Section mismatch: reference to .init.text:
      WARNING: fs/built-in.o(.cranges+0x14a): Section mismatch: reference to .init.text:
      WARNING: fs/built-in.o(.cranges+0x168): Section mismatch: reference to .init.text:
      WARNING: fs/built-in.o(.cranges+0x1f4): Section mismatch: reference to .init.text:
      WARNING: fs/built-in.o(.cranges+0x1fe): Section mismatch: reference to .init.text:
      WARNING: net/built-in.o(.cranges+0x302): Section mismatch: reference to .init.text:
      WARNING: net/built-in.o(.cranges+0x30c): Section mismatch: reference to .init.text:
      WARNING: net/built-in.o(.cranges+0x316): Section mismatch: reference to .init.text:
      WARNING: net/built-in.o(.cranges+0x3a2): Section mismatch: reference to .init.text:
      WARNING: net/built-in.o(.cranges+0x3ac): Section mismatch: reference to .init.text:
      WARNING: net/built-in.o(.cranges+0x4ce): Section mismatch: reference to .init.text:
      WARNING: net/built-in.o(.cranges+0x4d8): Section mismatch: reference to .init.text:
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      Cc: Kaz Kojima <kkojima@rr.iij4u.or.jp>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      2648a53a
  3. 22 5月, 2007 1 次提交
  4. 19 5月, 2007 8 次提交
  5. 10 5月, 2007 1 次提交
  6. 09 5月, 2007 1 次提交
    • Y
      Add white list into modpost.c for memory hotplug code and ia64's machvec section · 72280ede
      Yasunori Goto 提交于
      This patch is add white list into modpost.c for some functions and
      ia64's section to fix section mismatchs.
      
        sparse_index_alloc() and zone_wait_table_init() calls bootmem allocator
        at boot time, and kmalloc/vmalloc at hotplug time. If config
        memory hotplug is on, there are references of bootmem allocater(init text)
        from them (normal text). This is cause of section mismatch.
      
        Bootmem is called by many functions and it must be
        used only at boot time. I think __init of them should keep for
        section mismatch check. So, I would like to register sparse_index_alloc()
        and zone_wait_table_init() into white list.
      
        In addition, ia64's .machvec section is function table of some platform
        dependent code. It is mixture of .init.text and normal text. These
        reference of __init functions are valid too.
      Signed-off-by: NYasunori Goto <y-goto@jp.fujitsu.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      72280ede
  7. 08 5月, 2007 1 次提交
  8. 03 5月, 2007 11 次提交
  9. 21 2月, 2007 1 次提交
    • D
      [PATCH] remove modpost false warnings on ARM · da68d61f
      David Brownell 提交于
      This patch stops "modpost" from issuing erroneous modpost warnings on ARM
      builds, which it's been doing since 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 symbol **in the middle 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
      doesn't know should also include those "$d" mapping symbols, which are not
      otherwise associated with "<name>_driver" symbols.
      
      This patch prevents the modpost symbol lookup code from ever returning
      those mapping symbols, so it will return a whitelisted symbol instead.
      Then things work as expected.
      
      Now to revert various code-bloating "fixes" that got merged because of this
      modpost bug....
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Acked-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      da68d61f
  10. 17 2月, 2007 2 次提交