linux2.6.28.1编译时__mutex_unlock_slowpath未定义的错误

来源:互联网 发布:大仓忠义 知乎 编辑:程序博客网 时间:2024/05/16 06:04

    下午在编译2.6.28.1内核的时候,采用的是默认的x86_config的配置,make bzImage的时候报错,提示:

    undefined reference to __mutex_unlock_slowpath,

  上网搜索半天也得不到有用的结果,只好自己想办法了。首先索引内核源代码,看下__mutex_unlock_slowpath到底是何方神圣。在http://lxr.linux.no/linux/中得到的结果如下:

  

 268/* 269 * Release the lock, slowpath: 270 */ 271static noinline void 272__mutex_unlock_slowpath(atomic_t *lock_count) 273{ 274        __mutex_unlock_common_slowpath(lock_count, 1); 275} 276
  没发现任何问题,很明显代码中是存在了定义的。那为什么还是说找不到呢?只可能相关的宏定义没有打开的原因。继续搜索:

5#ifndef CONFIG_DEBUG_LOCK_ALLOC  56/*  57 * We split the mutex lock/unlock logic into separate fastpath and  58 * slowpath functions, to reduce the register pressure on the fastpath.  59 * We also put the fastpath first in the kernel image, to make sure the  60 * branch is predicted by the CPU as default-untaken.  61 */  62static void noinline __sched  63__mutex_lock_slowpath(atomic_t *lock_count);  64  65/***  66 * mutex_lock - acquire the mutex  67 * @lock: the mutex to be acquired  68 *  69 * Lock the mutex exclusively for this task. If the mutex is not  70 * available right now, it will sleep until it can get it.  71 *  72 * The mutex must later on be released by the same task that  73 * acquired it. Recursive locking is not allowed. The task  74 * may not exit without first unlocking the mutex. Also, kernel  75 * memory where the mutex resides mutex must not be freed with  76 * the mutex still locked. The mutex must first be initialized  77 * (or statically defined) before it can be locked. memset()-ing  78 * the mutex to 0 is not allowed.  79 *  80 * ( The CONFIG_DEBUG_MUTEXES .config option turns on debugging  81 *   checks that will enforce the restrictions and will also do  82 *   deadlock debugging. )  83 *  84 * This function is similar to (but not equivalent to) down().  85 */  86void inline __sched mutex_lock(struct mutex *lock)  87{  88        might_sleep();  89        /*  90         * The locking fastpath is the 1->0 transition from  91         * 'unlocked' into 'locked' state.  92         */  93        __mutex_fastpath_lock(&lock->count, __mutex_lock_slowpath);  94}  95  96EXPORT_SYMBOL(mutex_lock);  97#endif  98  99static noinline void __sched __mutex_unlock_slowpath(atomic_t *lock_count); 100 101/*** 102 * mutex_unlock - release the mutex 103 * @lock: the mutex to be released 104 * 105 * Unlock a mutex that has been locked by this task previously. 106 * 107 * This function must not be used in interrupt context. Unlocking 108 * of a not locked mutex is not allowed. 109 * 110 * This function is similar to (but not equivalent to) up(). 111 */ 112void __sched mutex_unlock(struct mutex *lock) 113{ 114        /* 115         * The unlocking fastpath is the 0->1 transition from 'locked' 116         * into 'unlocked' state: 117         */ 118        __mutex_fastpath_unlock(&lock->count, __mutex_unlock_slowpath); 119} 120



   发现CONFIG_DEBUG_LOCK_ALLOC控制了__mutex_unlock_slowpath的定义。打开.config搜索,看是否CONFIG_DEBUG_LOCK_ALLOC宏是否设置,发现设置了。那肯定还有另外的宏在起控制作用。继续搜索,发现如下结果:

    

  22/*  23 * In the DEBUG case we are using the "NULL fastpath" for mutexes,  24 * which forces all calls into the slowpath:  25 */  26#ifdef CONFIG_DEBUG_MUTEXES  27# include "mutex-debug.h"  28# include <asm-generic/mutex-null.h>  29#else  30# include "mutex.h"  31# include <asm/mutex.h>  32#endif  33

   可以看到CONFIG_DEBUG_MUTEXES控制了头文件的包含关系,再次在.config中搜索,发现CONFIG_DEBUG_MUTEXES宏果然没有定义。将其改成y,重新编译,通过。

   

原创粉丝点击