RE: backtrace/2325: wrong back trace on x86_64whenpthread_mutex_lock is the innermost function call. bitmode/kernelversion/compiler version are irrelevant

RE: backtrace/2325: wrong back trace on x86_64whenpthread_mutex_lock is the innermost function call. bitmode/kernelversion/compiler version are irrelevant

[Yan, Michael]

The following reply was made to PR backtrace/2325; it has been noted by GNATS.

From: "Yan, Michael" <myan@microstrategy.com>
To: "Daniel Jacobowitz" <drow@false.org>
Cc: <gdb-gnats@sources.redhat.com>
Subject: RE: backtrace/2325: wrong back trace on x86_64whenpthread_mutex_lock is the innermost function call. bitmode/kernelversion/compiler version are irrelevant
Date: Fri, 5 Oct 2007 16:34:40 -0400

 I tried RedHat AS 5 distribution which has glibc version 2.5. It works =
 fine.
 
 However, we have to support customers with glibc 2.3 which means we have =
 to patch that version. Do you know which change make the difference ? =
 Any information is appreciated.
 
 thanks,
 Michael
 
 -----Original Message-----
 From: Daniel Jacobowitz [mailto:drow@false.org]
 Sent: Friday, October 05, 2007 12:35 PM
 To: Yan, Michael
 Cc: gdb-gnats@sources.redhat.com
 Subject: Re: backtrace/2325: wrong back trace on
 x86_64whenpthread_mutex_lock is the innermost function call.
 bitmode/kernelversion/compiler version are irrelevant
 
 
 On Fri, Oct 05, 2007 at 12:24:38PM -0400, Yan, Michael wrote:
 > Hi Daniel,
 >=20
 > We are using glibc 2.3.2 and 2.3.4. Our customers use it too. Is
 > there a way to work around this on gdb side ?
 
 Not that I know of.
 
 --=20
 Daniel Jacobowitz
 CodeSourcery

Re: backtrace/2325: wrong back trace on x86_64whenpthread_mutex_lock is the innermost function call. bitmode/kernelversion/compiler version are irrelevant

[Daniel Jacobowitz]

The following reply was made to PR backtrace/2325; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@false.org>
To: "Yan, Michael" <myan@microstrategy.com>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: backtrace/2325: wrong back trace on
	x86_64whenpthread_mutex_lock is the innermost function call.
	bitmode/kernelversion/compiler version are irrelevant
Date: Fri, 5 Oct 2007 16:41:33 -0400

 On Fri, Oct 05, 2007 at 04:34:40PM -0400, Yan, Michael wrote:
 > I tried RedHat AS 5 distribution which has glibc version 2.5. It works fine.
 > 
 > However, we have to support customers with glibc 2.3 which means we have to patch that version. Do you know which change make the difference ? Any information is appreciated.
 
 I suspect it was this patch:
 
 2006-03-03  Jakub Jelinek  <jakub@redhat.com>
             Roland McGrath  <roland@redhat.com>
 
         * sysdeps/unix/sysv/linux/x86_64/lowlevellock.h
         (LLL_STUB_UNWIND_INFO_START, LLL_STUB_UNWIND_INFO_END,
         LLL_STUB_UNWIND_INFO_5, LLL_STUB_UNWIND_INFO_6): Define.
         (lll_mutex_lock, lll_robust_mutex_lock, lll_mutex_cond_lock,
         lll_robust_mutex_cond_lock, lll_mutex_timedlock,
         lll_robust_mutex_timedlock, lll_mutex_unlock,
         lll_robust_mutex_unlock, lll_lock, lll_unlock): Use them.
         Add _L_*_ symbols around the subsection.
         * sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: Add unwind
 	info.
         * sysdeps/unix/sysv/linux/x86_64/lowlevelrobustlock.S:
 	Likewise.
 
 However, patching glibc is difficult; I can't promise that patch will
 work on any other version.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery