From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29370 invoked by alias); 15 Jan 2010 17:46:32 -0000 Received: (qmail 29362 invoked by uid 22791); 15 Jan 2010 17:46:31 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 Jan 2010 17:46:26 +0000 Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id BB4A74F052; Fri, 15 Jan 2010 09:46:22 -0800 (PST) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost4.vmware.com (Postfix) with ESMTP id AF915C9A2D; Fri, 15 Jan 2010 09:46:22 -0800 (PST) Message-ID: <4B50AA06.8050900@vmware.com> Date: Fri, 15 Jan 2010 17:46:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20090624) MIME-Version: 1.0 To: Jan Kratochvil CC: "gdb-patches@sourceware.org" Subject: Re: [rfc] Fix "step" for ld.so debugging [Re: [RFC] problem in solib-svr4/enable_break] References: <4B4F95C3.5080209@vmware.com> <20100115004405.GB26561@host0.dyn.jankratochvil.net> In-Reply-To: <20100115004405.GB26561@host0.dyn.jankratochvil.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-01/txt/msg00408.txt.bz2 Jan Kratochvil wrote: > Hi Michael, > > I see there is a problem for debugging ld.so even on native GNU/Linux when > I get some intentional way into the ld.so code. Existing problem: > (gdb) frame > #0 _dl_fixup (l=0x7ffff7ffe0e8, reloc_arg=) at ../elf/dl-runtime.c:90 > 90 if (__builtin_expect (ELFW(ST_VISIBILITY) (sym->st_other), 0) == 0) > (gdb) next > 94 if (l->l_info[VERSYMIDX (DT_VERSYM)] != NULL) > (gdb) next > 99 version = &l->l_versions[ndx]; > (gdb) next > 100 if (version->hash == 0) > (gdb) step > pause () at ../sysdeps/unix/syscall-template.S:82 > 82 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) > > ("next" works but "step" skips whole ld.so resolver) > > Wouldn't the patch below also solve your "PIE kernel" problem? > > No regressions on {x86_64,x86_64-m32,i686}-fedora12-linux-gnu. > But I am not much sure about some possible regressions with this code. Jan, thanks, I can see the logic, and it does indeed fix my symptom. Are you thinking of checking it in?