From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12100 invoked by alias); 20 May 2011 11:58:11 -0000 Received: (qmail 12090 invoked by uid 22791); 20 May 2011 11:58:10 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_EG,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 May 2011 11:57:56 +0000 Received: (qmail 9431 invoked from network); 20 May 2011 11:57:55 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 20 May 2011 11:57:55 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: Regression loading a tracefile in 7_3 Date: Fri, 20 May 2011 11:58:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-28-generic; KDE/4.6.2; x86_64; ; ) Cc: Marc Khouzam References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105201257.53942.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-05/txt/msg00107.txt.bz2 On Friday 20 May 2011 03:03:20, Marc Khouzam wrote: > Hi, > > I believe I'm seeing a regression loading a tracefile in GDB 7.3 > I create a simple tracefile using GDB/gdbserver 7.3 but when I try to load > that tracefile, I get an error about "PC register is not available", which > causes my Eclipse session to abort. This is not happening in 7.2 or 7.2.1. > > > gdb.7.3 a.out > GNU gdb (GDB) 7.2.90.20110519-cvs > (gdb) interpreter-exec mi "-target-select tfile trace.7.3" > ~"Created tracepoint 1 for target's tracepoint 1 at 0x804851f.\n" > ^error,msg="PC register is not available" > Hmm. #0 throw_error (error=NOT_AVAILABLE_ERROR, fmt=0x7f7908 "PC register is not available") at ../../src/gdb/exceptions.c:423 #1 0x000000000053de3a in regcache_read_pc (regcache=0xd4b280) at ../../src/gdb/regcache.c:994 #2 0x0000000000497053 in enable_break (info=0xd0df60, from_tty=1) at ../../src/gdb/solib-svr4.c:1536 #3 0x00000000004980a8 in svr4_solib_create_inferior_hook (from_tty=1) at ../../src/gdb/solib-svr4.c:2194 #4 0x000000000046faa7 in solib_create_inferior_hook (from_tty=1) at ../../src/gdb/solib.c:1240 #5 0x0000000000586de2 in post_create_inferior (target=0xbc7120, from_tty=1) at ../../src/gdb/infcmd.c:427 #6 0x00000000004d2ca8 in tfile_open (filename=0xd0d790 "/home/pedro/gdb/marck_tfile/build/gdb/./testsuite/basic.tf", from_tty=1) at ../../src/gdb/tracepoint.c:3410 Here, in solib-svr4.c: /* Otherwise we find the dynamic linker's base address by examining the current pc (which should point at the entry point for the dynamic linker) and subtracting the offset of the entry point. This is more fragile than the previous approaches, but is a good fallback method because it has actually been working well in most cases. */ if (!load_addr_found) { struct regcache *regcache = get_thread_arch_regcache (inferior_ptid, target_gdbarch); load_addr = (regcache_read_pc (regcache) - exec_entry_point (tmp_bfd, tmp_bfd_target)); } We could skip this if the PC is not available, but: - why do we even try to set a shared library breakpoint if the target has no execution (e.g., when debugging a core file) in the first place? I'll skipping enable_break in that case and see if anything breaks. By inspection, it looks like nothing will. svr4_in_dynsym_resolve_code will always return false if we skip enable_break, but then again that function is only used for run control. (Hmm, that fallback assumes the program is stopped at the dynamic loader's entry point, which isn't a safe assumption when we attach to an inferior rather than spawning it. Might be better to try anyway than not do anything at all though.) -- Pedro Alves