From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13841 invoked by alias); 5 Jun 2009 13:43:59 -0000 Received: (qmail 13833 invoked by uid 22791); 5 Jun 2009 13:43:58 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 05 Jun 2009 13:43:50 +0000 Received: (qmail 5477 invoked from network); 5 Jun 2009 13:43:48 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Jun 2009 13:43:48 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: ptid from core section Date: Fri, 05 Jun 2009 13:43:00 -0000 User-Agent: KMail/1.9.10 Cc: Aleksandar Ristovski References: <4A23F9FF.8040708@qnx.com> <200906031941.55106.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906051444.37443.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00095.txt.bz2 On Thursday 04 June 2009 19:31:58, Aleksandar Ristovski wrote: > Pedro Alves wrote: > > This is mostly OK as far as I'm concerned. One question though: > > > >> (ptid_from_core_section, core_section_name_from_ptid): New > >> functions. > > > > Is there still a reason the former takes bfd and bfd section pointers, > > instead of being a mirror of the latter (say, ptid_from_core_section_name)? > > > > Not a good reason. I just used what was available at the > calling site. The attached patch makes arguments of the two > new callbacks symmetrical (as much as was possible) as well > as makes their names symmetrical. > > This time, gdbarch.[ch] included. > > Hmm, sorry I missed something before... AFAICS, core_gdbarch can end up being left NULL. Most code that accesses it in corelow.c handles it's NULL-ness, while your change adds some unconditional accesses. The path of least resistence to fix this, is to move the callback defaults to corelow.c, make the new callbacks optional, and check for 'core_gdbarch && gdbarch_foo_p (core_gdbarch)' predicates before calling the optional callbacks. ( This does raise the question of which gdbarch is the best in these case: core_gdbarch; the executable's gdbarch; the more refined target_gdbarch, which in turn is refined from current_gdbarch through core_read_description. Yuk. ) -- Pedro Alves