From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6559 invoked by alias); 20 Jul 2009 14:43:12 -0000 Received: (qmail 6540 invoked by uid 22791); 20 Jul 2009 14:43:11 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-fx0-f210.google.com (HELO mail-fx0-f210.google.com) (209.85.220.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Jul 2009 14:43:04 +0000 Received: by fxm6 with SMTP id 6so1932406fxm.24 for ; Mon, 20 Jul 2009 07:43:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.252.17 with SMTP id e17mr2268194mus.14.1248100981029; Mon, 20 Jul 2009 07:43:01 -0700 (PDT) In-Reply-To: <20090720120323.GA27912@caradoc.them.org> References: <74fef6df0907200417q503ca457m642ebab9d953edb@mail.gmail.com> <20090720120323.GA27912@caradoc.them.org> Date: Mon, 20 Jul 2009 14:43:00 -0000 Message-ID: <74fef6df0907200743x51c18b2cva6dc22d493265a45@mail.gmail.com> Subject: Re: _r_debug_state getting screwed on x86_64 ? From: Mathieu Lacage To: Mathieu Lacage , gdb@sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: 2009-07/txt/msg00140.txt.bz2 On Mon, Jul 20, 2009 at 2:03 PM, Daniel Jacobowitz wrote: >> (gdb) si >> warning: Temporarily disabling breakpoints for unloaded shared library "= ../ldso" >> Stopped due to shared library event > > This is your problem. =C2=A0You're supposed to have ldso in the list > already. ha, I see: thanks for putting me on the right track. 1) gdb initializes its linkmap from the inferior's PT_INTERP (coming from its auxv) 2) when the dynamic loader calls _r_debug_state for the first time, gdb iterates over the linkmap and assumes that any item which is present in its own linkmap and which is not present in the inferior's linkmap has been unloaded. In my case, the filename of the ldso entry in the inferior's linkmap did not match _exactly_ the inferior's main PT_INTERP so, gdb wrongly assumed it was unloaded. Then, it disabled the breakpoint from the inferior's _r_debug_state, hence, leaving around the int3 I observed below. > >> ------------ and, yes, we can see the gdb int3 instruction in the >> function. ------------- > > And that's not a feature. =C2=A0You should never be able to observe gdb's > software breakpoints by reading memory with GDB; if you do, it means > something has already gone wrong. I just had to adjust the filename field of my inferior's ldso entry in the linkmap, and, gone were the crashes :) Mathieu --=20 Mathieu Lacage