From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16022 invoked by alias); 7 May 2004 00:48:58 -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 16013 invoked from network); 7 May 2004 00:48:57 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 7 May 2004 00:48:57 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id BCA8E357B; Thu, 6 May 2004 17:48:55 -0700 (PDT) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.9/8.12.9) with ESMTP id i470mtOi024644; Thu, 6 May 2004 17:48:55 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id i470msLC024640; Thu, 6 May 2004 17:48:54 -0700 Date: Fri, 07 May 2004 00:48:00 -0000 Message-Id: <200405070048.i470msLC024640@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [obish?sym;rfa:doc] Wire up vsyscall In-Reply-To: Andrew Cagney's message of Thursday, 6 May 2004 15:04:10 -0400 <409A8C2A.2010605@gnu.org> Emacs: the Swiss Army of Editors. X-SW-Source: 2004-05/txt/msg00165.txt.bz2 > 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. > 2. bfd_elf_bfd_from_remote_memory requires an existing bfd > For the case: > $ ./gdb > (gdb) attach > that isn't necessarially so. 1. will fix this. I used a bfd argument this way because the functions I saw handy to do target-integer-format extraction used a bfd argument. Not knowing BFD too well, I probably overlooked some other way to get at that info. > 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'm not clear on what you mean by "reload the vsyscall page" here. What needs to happen on a repeated run is to repeat from scratch all the vsyscall-page-related work that was done on the first run/attach. That is, all of the details can turn out different on each new exec: whether or not AT_SYSINFO_EHDR is supplied at all; the address of the page; the contents of the page, i.e. its symbol table and unwind info. 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. > + /* 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. Of course the details of the workaround don't matter if the problem is being fixed properly quite soon. > + 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" > + /* Want to know of each new inferior so that it's vsyscall info can > + be extracted. */ Typo here: it's -> its. > +@var{GDBN} has just created to a new inferior. For @samp{run}, it is Extra word here: ^^ > +immediatly after opening the inferior (and before any information on Typo here: immediatly -> immediately. > but remember I intend changing the second to: > > ... > #1 0x1234 in > ... That's a nice improvement anyway. I have never liked the hiding of the PC value. Thanks, Roland