From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Description of problem: In nptl/sysdeps/unix/sysv/linux/i386/lowlevellock.h, the symbols _L_mutex_lock_%= _L_mutex_cond_lock_%= _L_mutex_timedlock_%= _L_mutex_unlock_%= are given a .type of @function. However, these symbols violate two important properties of standard functions: the return address is not at the top of the stack upon entry, and saved registers (typically %ebp and %esi) do not have the same values on exit as on entry. These violations make life difficult for auditing tools, both static and dynamic. The incorrect .type and .sizeof declarations should be removed. Version-Release number of selected component (if applicable): glibc-2.3.2-101.4 How reproducible: Always Steps to Reproduce: 1. Inspect source. 2. readelf --symbols /lib/tls/libc.so.6 | grep _L_mutex_ 3. gdb /lib/tls/libc.so.6 ; disassemble and trace path to 'ret'. Actual Results: 2. 132: 00b3ea68 16 FUNC LOCAL DEFAULT 11 _L_mutex_lock_21 [etc.] 3. $ gdb /lib/tls/libc.so.6 (gdb) x/6i _L_mutex_lock_21 0xb3ea68 <_L_mutex_lock_21>: lea 0x320(%ebx),%ecx 0xb3ea6e <_L_mutex_lock_21+6>: call 0xc0ebb0 <__lll_mutex_lock_wait> 0xb3ea73 <_L_mutex_lock_21+11>: jmp 0xb3dcf4 <__gconv_get_path+52> 0xb3ea78 <_L_mutex_unlock_32>: lea 0x320(%ebx),%eax 0xb3ea7e <_L_mutex_unlock_32+6>: call 0xc0ec00 <__lll_mutex_unlock_wake> 0xb3ea83 <_L_mutex_unlock_32+11>: jmp 0xb3dd17 <__gconv_get_path+87> (gdb) x/6i 0xb3dd17 0xb3dd17 <__gconv_get_path+87>: lea 0xfffffff4(%ebp),%esp 0xb3dd1a <__gconv_get_path+90>: pop %ebx 0xb3dd1b <__gconv_get_path+91>: pop %esi 0xb3dd1c <__gconv_get_path+92>: pop %edi 0xb3dd1d <__gconv_get_path+93>: pop %ebp 0xb3dd1e <__gconv_get_path+94>: ret Expected Results: Symbols should not have .type @function unless the return address is at the top of the stack on entry, and unless saved registers have the same values on exit as on entry. Additional info: The offending .type @function may have been introduced in glibc-2.3.2-200309100550 .
The correct execution path for _L_mutex_lock_21 is the earlier 0xb3ea73 <_L_mutex_lock_21+11>: jmp 0xb3dcf4 <__gconv_get_path+52> which leads to (gdb) x/13i 0xb3dcf4 0xb3dcf4 <__gconv_get_path+52>: mov 0x29e0(%ebx),%eax 0xb3dcfa <__gconv_get_path+58>: test %eax,%eax 0xb3dcfc <__gconv_get_path+60>: je 0xb3dd1f <__gconv_get_path+95> 0xb3dcfe <__gconv_get_path+62>: cmpl $0x0,%gs:0xc 0xb3dd06 <__gconv_get_path+70>: je,pt 0xb3dd0a <__gconv_get_path+74> 0xb3dd09 <__gconv_get_path+73>: lock subl $0x1,0x320(%ebx) 0xb3dd11 <__gconv_get_path+81>: jne 0xb3ea78 <_L_mutex_unlock_32> 0xb3dd17 <__gconv_get_path+87>: lea 0xfffffff4(%ebp),%esp 0xb3dd1a <__gconv_get_path+90>: pop %ebx 0xb3dd1b <__gconv_get_path+91>: pop %esi 0xb3dd1c <__gconv_get_path+92>: pop %edi 0xb3dd1d <__gconv_get_path+93>: pop %ebp 0xb3dd1e <__gconv_get_path+94>: ret
I'm not aware of anything which would back up your definition of STT_FUNC. gABI says about it: "The symbol is associated with a function or other executable code." _L_mutex_lock is certainly associated with executable code, so should have STT_FUNC.
This is no bug. The symbol type is _exactly_ right.