From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24933 invoked by alias); 15 Jan 2010 00:44:17 -0000 Received: (qmail 24919 invoked by uid 22791); 15 Jan 2010 00:44:16 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 Jan 2010 00:44:12 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o0F0i8vT015559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 14 Jan 2010 19:44:09 -0500 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o0F0i6GV020818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Jan 2010 19:44:08 -0500 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.3/8.14.3) with ESMTP id o0F0i6gh027069; Fri, 15 Jan 2010 01:44:06 +0100 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.3/8.14.3/Submit) id o0F0i5dq027066; Fri, 15 Jan 2010 01:44:05 +0100 Date: Fri, 15 Jan 2010 00:44:00 -0000 From: Jan Kratochvil To: Michael Snyder Cc: "gdb-patches@sourceware.org" Subject: [rfc] Fix "step" for ld.so debugging [Re: [RFC] problem in solib-svr4/enable_break] Message-ID: <20100115004405.GB26561@host0.dyn.jankratochvil.net> References: <4B4F95C3.5080209@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B4F95C3.5080209@vmware.com> User-Agent: Mutt/1.5.20 (2009-08-17) 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/msg00397.txt.bz2 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. Regards, Jan 2010-01-15 Jan Kratochvil * infrun.c (handle_inferior_event): Continue stepping through dynsym resolve code only if STEP_RANGE_START was not in dynsym resolve code. --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -4115,8 +4115,9 @@ infrun: not switching back to stepped thread, it has vanished\n"); /* If we are stepping at the source level and entered the runtime loader dynamic symbol resolution code... - EXEC_FORWARD: we keep on single stepping until we exit the run - time loader code and reach the callee's address. + EXEC_FORWARD: we keep on single stepping until we exit the run time loader + code and reach the callee's address. Permit normal stepping inside loader + code if user already started the stepping there. EXEC_REVERSE: we've already executed the callee (backward), and the runtime loader code is handled just like any other @@ -4126,7 +4127,9 @@ infrun: not switching back to stepped thread, it has vanished\n"); if (execution_direction != EXEC_REVERSE && ecs->event_thread->step_over_calls == STEP_OVER_UNDEBUGGABLE - && in_solib_dynsym_resolve_code (stop_pc)) + && in_solib_dynsym_resolve_code (stop_pc) + && !(ecs->event_thread->step_range_start > 1 + && in_solib_dynsym_resolve_code (ecs->event_thread->step_range_start))) { CORE_ADDR pc_after_resolver = gdbarch_skip_solib_resolver (gdbarch, stop_pc);