From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29738 invoked by alias); 7 May 2004 01:31:00 -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 29726 invoked from network); 7 May 2004 01:30:59 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 7 May 2004 01:30:59 -0000 Received: from drow by nevyn.them.org with local (Exim 4.32 #1 (Debian)) id 1BLuCX-0007vd-Bh; Thu, 06 May 2004 21:30:57 -0400 Date: Fri, 07 May 2004 01:31:00 -0000 From: Daniel Jacobowitz To: Roland McGrath Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [obish?sym;rfa:doc] Wire up vsyscall Message-ID: <20040507013057.GB30182@nevyn.them.org> Mail-Followup-To: Roland McGrath , Andrew Cagney , gdb-patches@sources.redhat.com References: <409A8C2A.2010605@gnu.org> <200405070048.i470msLC024640@magilla.sf.frob.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200405070048.i470msLC024640@magilla.sf.frob.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-05/txt/msg00176.txt.bz2 On Thu, May 06, 2004 at 05:48:54PM -0700, Roland McGrath wrote: > > At present I know of the following problems: > > > > 1. The code assumes ELF support in BFD > > Per recent BFD posts, I'm fixing this. > > I didn't find what you're referring to in a quick scan of the archives. > Can you give me a specific URL in the mailing list archive, or an exact > subject line to search for? I participated in the discussion about the > issue, but I don't recall a posting from you proposing changes to address it. See the binutils list, where Andrew has been reimplementing the underlying I/O mechanism lately. > > 3. inferior recycle VS inferior create > > Because GDB currently fudges things by recycling the inferior at each > > run (instead of creating a new fresh inferior) symfile tries to reload > > the vsyscall page. Doesn't do any harm fortunatly. Having a proper > > inferior will fix this. I don't see how this is different than any other shared library. I think we already set a flag that causes the objfile to be discarded at re-run (OBJF_SHARED) unless this has been lost somewhere? > I don't know the status of the "catch exec" functionality. > But if that works at all, it needs to do this observer notification too. > Otherwise the patch looks good to me modulo the following tiny nits. It doesn't work. It's broken by design; I have patches that make it "work" again, but I never submitted them because both the code and the interface are so ugly. > > + /* 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. Unfortunatly 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. */ > > + return; > > I think there should be an error thrown or at least a warning message here, > instead of just silent not-doing. The user can then do "file" before > "attach" to make the backtraces work. I agree. > > + printf_unfiltered ("Loaded system supplied DSO at 0x%s\n", > > + paddr_nz (sysinfo_ehdr)); > > I don't know if printf_unfiltered means this or not, but this output should > only appear under `set verbose on'. Also, I would change the message to > fix the grammar and to be consistent with other gdb messages: > > "Reading symbols from system-supplied DSO at 0x%s\n" Either set verbose, or at least propogate from_tty here. Right now the thread_db message is the only thing in startup that disregards from_tty (I've been meaning to fix this for ages). -- Daniel Jacobowitz