From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119226 invoked by alias); 18 Sep 2015 12:02:05 -0000 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 Received: (qmail 119216 invoked by uid 89); 18 Sep 2015 12:02:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-wi0-f173.google.com Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 18 Sep 2015 12:02:02 +0000 Received: by wicge5 with SMTP id ge5so29692574wic.0 for ; Fri, 18 Sep 2015 05:01:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=1IYJlTSmqaEytHauAKeeg5u6ccKkIyFhwEnsqr/dggw=; b=QNpqxUboh5rIacCeYPLK3zMMyFxAwo3T2iwoPSg4ssnb9W1LvWZLcE3dh3sALErOFQ np+PJ8l1SXL5mf6Ms0nXLkdDHZQxMAjJIF0txXSGid3Iik20nMDdvSK4i18Nf8x0saj2 brU3OLojmaTcYjIb8xgJ5TbDYHG03Su3y0P28iBqWjTKrThnHOMWSzCAY6KsoImZa3HQ aiVVjGEv72cG2Ixzg/PpDsRs1Tv/Zt8MDau67xVoJ0KE02jFFK7rJHXZG/Tqlfe9NRQP Xm0SiypJGFhGyqiW2GHPZ/YEz/gr+xmm9f9FAZ8d6IvJw95Nf7VFEWIHxwBTevi4UmBj O2tw== X-Gm-Message-State: ALoCoQkzfuHU1oZylJs8JwvicqXieip36vbyo/TI0n6/qm//VKtYJ/HeRnG8OAr3A7Htr/U+AcXS X-Received: by 10.180.189.102 with SMTP id gh6mr36081183wic.95.1442577719418; Fri, 18 Sep 2015 05:01:59 -0700 (PDT) Received: from localhost (host81-131-206-173.range81-131.btcentralplus.com. [81.131.206.173]) by smtp.gmail.com with ESMTPSA id i9sm8524500wjz.20.2015.09.18.05.01.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Sep 2015 05:01:58 -0700 (PDT) Date: Fri, 18 Sep 2015 12:02:00 -0000 From: Andrew Burgess To: Kevin Buettner Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 2/8] Add new gdbarch method, unconditional_branch_address Message-ID: <20150918120157.GB10919@embecosm.com> References: <20150818235334.1afb0c85@pinnacle.lan> <20150819000002.06f6a2cf@pinnacle.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150819000002.06f6a2cf@pinnacle.lan> X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00447.txt.bz2 * Kevin Buettner [2015-08-19 00:00:02 -0700]: > diff --git a/gdb/gdbarch.h b/gdb/gdbarch.h > index c1e2c1a..1770960 100644 > --- a/gdb/gdbarch.h > +++ b/gdb/gdbarch.h > @@ -924,7 +924,7 @@ extern void set_gdbarch_max_insn_length (struct gdbarch *gdbarch, ULONGEST max_i > If your architecture doesn't need to adjust instructions before > single-stepping them, consider using simple_displaced_step_copy_insn > here. > - > + > If the instruction cannot execute out of line, return NULL. The > core falls back to stepping past the instruction in-line instead in > that case. */ > @@ -1478,6 +1478,16 @@ typedef int (gdbarch_addressable_memory_unit_size_ftype) (struct gdbarch *gdbarc > extern int gdbarch_addressable_memory_unit_size (struct gdbarch *gdbarch); > extern void set_gdbarch_addressable_memory_unit_size (struct gdbarch *gdbarch, gdbarch_addressable_memory_unit_size_ftype *addressable_memory_unit_size); > > +/* Examine instruction at PC. If instruction at PC is an unconditional > + branch, return the address to which control is transferred when the > + branch is taken. Return 0 when this method is not implemented by > + architecture, PC refers to an invalid address, or instruction at PC > + is not an unconditional branch. */ > + > +typedef CORE_ADDR (gdbarch_unconditional_branch_address_ftype) (struct gdbarch *gdbarch, CORE_ADDR pc); > +extern CORE_ADDR gdbarch_unconditional_branch_address (struct gdbarch *gdbarch, CORE_ADDR pc); > +extern void set_gdbarch_unconditional_branch_address (struct gdbarch *gdbarch, gdbarch_unconditional_branch_address_ftype *unconditional_branch_address); Personally I'm not a fan of overloading the return values on these functions, especially when the return value is an address, on some targets 0 is a valid address. I know there are lots of other places where we use 0 as a special address in gdb, so this would be just one more... but... How would you feel about changing the function so that it returned a bool and placed the address into a CORE_ADDRESS passed by pointer? Just a thought, thanks Andrew