From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22320 invoked by alias); 23 Jul 2013 04:16:59 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 19868 invoked by uid 48); 23 Jul 2013 04:14:56 -0000 From: "andi-bz at firstfloor dot org" To: glibc-bugs@sourceware.org Subject: [Bug nptl/15771] New: __lll_unlock_wake break perf/libunwind unwinding Date: Tue, 23 Jul 2013 04:16:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: 2.17 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: andi-bz at firstfloor dot org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-07/txt/msg00139.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=15771 Bug ID: 15771 Summary: __lll_unlock_wake break perf/libunwind unwinding Product: glibc Version: 2.17 Status: NEW Severity: normal Priority: P2 Component: nptl Assignee: unassigned at sourceware dot org Reporter: andi-bz at firstfloor dot org CC: drepper.fsp at gmail dot com Created attachment 7113 --> http://sourceware.org/bugzilla/attachment.cgi?id=7113&action=edit mutex test case Something in the way the x86-64 dwarf unwind table is written for __lll_unlock_wake breaks perf's libunwind implementation This is a problem because it makes it hard to track down lock contention in pthread programs. When profiling the attached test case with perf record -g dwarf ... perf report we get perf/libunwind: |--57.28%-- futex_wake | do_futex | sys_futex | system_call_fastpath | __lll_unlock_wake | | | |--80.89%-- 0x0 | | | |--18.73%-- _L_unlock_701 | --0.38%-- [...] The unwind always stops inside __lll_unlock_wake gdb can backtrace through it #0 0x000000326fe0de8a in __lll_unlock_wake () from /lib64/libpthread.so.0 #1 0x000000326fe0aae3 in _L_unlock_701 () from /lib64/libpthread.so.0 #2 0x000000326fe0aa6e in pthread_mutex_unlock () from /lib64/libpthread.so.0 #3 0x0000000000400809 in thread (arg=0x0) at tmutex.c:14 #4 0x000000326fe07c53 in start_thread () from /lib64/libpthread.so.0 #5 0x000000326faf513d in clone () from /lib64/libc.so.6 The glibc backtrace used by mutrace also seems to work. This is on FC19 with 3.10 perf and libunwind-1.1-2.fc19.x86_64 -- You are receiving this mail because: You are on the CC list for the bug.