• Alan Stern's avatar
    [PATCH] Workaround for gcc 2.96 (undefined references) · e0f39591
    Alan Stern authored
      LD      .tmp_vmlinux1
    mm/built-in.o(.text+0x100d6): In function `copy_page_range':
    : undefined reference to `__pud_alloc'
    mm/built-in.o(.text+0x1010b): In function `copy_page_range':
    : undefined reference to `__pmd_alloc'
    mm/built-in.o(.text+0x11ef4): In function `__handle_mm_fault':
    : undefined reference to `__pud_alloc'
    fs/built-in.o(.text+0xc930): In function `install_arg_page':
    : undefined reference to `__pud_alloc'
    make: *** [.tmp_vmlinux1] Error 1
    
    Those missing references in mm/memory.c arise from this code in
    include/linux/mm.h, combined with the fact that __PGTABLE_PMD_FOLDED and
    __PGTABLE_PUD_FOLDED are both set and __ARCH_HAS_4LEVEL_HACK is not:
    
    /*
     * The following ifdef needed to get the 4level-fixup.h header to work.
     * Remove it when 4level-fixup.h has been removed.
     */
    #if defined(CONFIG_MMU) && !defined(__ARCH_HAS_4LEVEL_HACK)
    static inline pud_t *pud_alloc(struct mm_struct *mm, pgd_t *pgd, unsigned long address)
    {
            return (unlikely(pgd_none(*pgd)) && __pud_alloc(mm, pgd, address))?
                    NULL: pud_offset(pgd, address);
    }
    
    static inline pmd_t *pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long address)
    {
            return (unlikely(pud_none(*pud)) && __pmd_alloc(mm, pud, address))?
                    NULL: pmd_offset(pud, address);
    }
    #endif /* CONFIG_MMU && !__ARCH_HAS_4LEVEL_HACK */
    
    With my configuration the pgd_none and pud_none routines are inlines
    returning a constant 0.  Apparently the old compiler avoids generating
    calls to __pud_alloc and __pmd_alloc but still lists them as undefined
    references in the module's symbol table.
    
    I don't know which change caused this problem.  I think it was added
    somewhere between 2.6.14 and 2.6.15-rc1, because I remember building
    several 2.6.14-rc kernels without difficulty.  However I can't point to an
    individual culprit.
    Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    e0f39591
memory.c 61.1 KB