Bug 115829

Summary: _L_mutex_lock_ is not a function, but has .type @function
Product: [Fedora] Fedora Reporter: John Reiser <jreiser>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 1CC: drepper, roland
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-02-18 19:14:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description John Reiser 2004-02-16 15:21:49 UTC
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 .

Comment 1 John Reiser 2004-02-16 15:30:39 UTC
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


Comment 2 Jakub Jelinek 2004-02-18 14:09:01 UTC
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.

Comment 3 Ulrich Drepper 2004-02-18 19:14:18 UTC
This is no bug.  The symbol type is _exactly_ right.