From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66157 invoked by alias); 8 Dec 2017 20:03:14 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 66148 invoked by uid 89); 8 Dec 2017 20:03:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=H*c:alternative, me, super X-HELO: mail-ot0-f176.google.com Received: from mail-ot0-f176.google.com (HELO mail-ot0-f176.google.com) (74.125.82.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Dec 2017 20:03:12 +0000 Received: by mail-ot0-f176.google.com with SMTP id y10so10077453otg.10 for ; Fri, 08 Dec 2017 12:03:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=69ssw6hc0p8SXLpcXEoG1Qv6ssmLONQsArf9kiY0iTE=; b=ERoFSpmYN5hmcXi3fzf7YRa5ix05FpE5B5JyHoJbXlTqJ/tIiV3jwzNtTrYjtC7gin cGuiB9aqq/iO2CxddPbutINmPjjZGgBF3d0Sts7wPMa9abtdRY/2uzZ8KuLy3ITxhr36 eHWa0NGW9ss9mEyvdRX6IHI5F4FWxcwgDGdXwV8KNGqFv9OZPe/YxdfXi9aiJS5ImPn+ MFv3m7onodGSNkJv3UFNABZ9WiGmVzXrPD4sC0oaDNR3VuGNisZyMa/Tf/XzVu49A4R8 bbVe61FfWTsWVmcrPRFvgvNO1nWkacwgYYs26xwW1bEKaTFdgAgawnxNqrd+brFRo/fj 8xkA== X-Gm-Message-State: AJaThX4cPciQBK0AGIMbCUkXPc2C8YGrjixFlLg4oRI29nXdbc/Bk3dg H7zEFNenF35kJhpxODXQnfHll0RpqEf8AiwpFqKWUsCv X-Google-Smtp-Source: AGs4zMZmdnvfEjICsc3GWvtNLZ+rGCHy2poEhNGToSYWeGK0K6Gu3hI5A2mGqvkhqZ7AnFzH975hnVoGsx3uBTW4u/E= X-Received: by 10.157.36.133 with SMTP id z5mr26678080ota.275.1512763390527; Fri, 08 Dec 2017 12:03:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.168.66.197 with HTTP; Fri, 8 Dec 2017 12:03:10 -0800 (PST) In-Reply-To: <20171208122016.B8336D8043A@oc3748833570.ibm.com> References: <20171208122016.B8336D8043A@oc3748833570.ibm.com> From: Tim Newsome Date: Fri, 08 Dec 2017 20:03:00 -0000 Message-ID: Subject: Re: gdbarch_init, ABI, and registers To: Ulrich Weigand Cc: gdb Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00011.txt.bz2 On Fri, Dec 8, 2017 at 4:20 AM, Ulrich Weigand wrote: > No, this doesn't look correct to me. Note that it is normal during > GDB operation that several different gdbarch objects are in use, > which have somewhat different contents and are used for different > purposes. > Ah! This is super helpful, and what I was missing. I'm adding it as a comment to `struct gdbarch`. Am I right in that riscv_gdbarch_init() can differentiate these two cases based on whether a target description is passed in or not? Eg. if there is a target description, register structures need to be set up, and if there isn't then that's not necessary? I guess I still haven't quite understood why exactly any of this > is causing a problem for you. Yes, gdbarch objects returned from > gdbarch_from_bfd will not have correct register info. But those > objects also should never be used in any context where registers > matter. Can you be more specific what the actual problem you're > seeing is? > The problem I was seeing is that registers were showing up which shouldn't. The reason (as I understand it now) is that I was depending on global variables in riscv-tdep.c instead of putting them in gdbarch.data. I'll make that change, and hopefully then everything will be better. Thank you, Tim