From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20438 invoked by alias); 11 Nov 2004 21:22:26 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20421 invoked from network); 11 Nov 2004 21:22:21 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 11 Nov 2004 21:22:21 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iABLMF9g031716 for ; Thu, 11 Nov 2004 16:22:21 -0500 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iABLMEr03252; Thu, 11 Nov 2004 16:22:14 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 112DF129D8C; Thu, 11 Nov 2004 16:21:03 -0500 (EST) Message-ID: <4193D7BC.50704@gnu.org> Date: Thu, 11 Nov 2004 21:22:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Jeff Johnston , Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [RFA]: Watchpoints per thread patch References: <01c4bca9$Blat.v2.2.2$adcffb00@zahav.net.il> <418A741C.4080306@redhat.com> <20041105044917.GA13554@nevyn.them.org> <418BAFC9.6050705@gnu.org> <20041105182850.GA22533@nevyn.them.org> <418FE5E7.3070501@gnu.org> <20041109010425.GA31431@nevyn.them.org> <4190292D.5070103@gnu.org> <20041109023306.GA1797@nevyn.them.org> <4190DDC8.5050004@gnu.org> <20041109184128.GA13359@nevyn.them.org> In-Reply-To: <20041109184128.GA13359@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00249.txt.bz2 > As for vsyscall, my memory may be faulty. It happens to me a lot > lately. I was thinking of the delay while the observers mechanism was > extended, and the partial xfer mechanism created. What do you mean by > "attach doesn't work now"? /* FIXME: cagney/2004-05-06: Should not require an existing BFD when trying to create a run-time BFD of the VSYSCALL page in the inferior. Unfortunately that's the current interface so for the moment bail. Introducing a ``bfd_runtime'' (a BFD created using the loaded image) file format should fix this. */ { warning ("could not load vsyscall page because no executable was specified"); warning ("try using the \"file\" command first"); return; }