Bug 115829 - _L_mutex_lock_ is not a function, but has .type @function
_L_mutex_lock_ is not a function, but has .type @function
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-16 10:21 EST by John Reiser
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-18 14:14:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description John Reiser 2004-02-16 10:21:49 EST
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 10:30:39 EST
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 09:09:01 EST
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 14:14:18 EST
This is no bug.  The symbol type is _exactly_ right.

Note You need to log in before you can comment on or make changes to this bug.