From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122400 invoked by alias); 8 Dec 2017 12:20:31 -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 122078 invoked by uid 89); 8 Dec 2017 12:20:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Dec 2017 12:20:24 +0000 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB8C3t9A050126 for ; Fri, 8 Dec 2017 07:20:23 -0500 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0b-001b2d01.pphosted.com with ESMTP id 2eqsputu97-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 08 Dec 2017 07:20:22 -0500 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 8 Dec 2017 12:20:20 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 8 Dec 2017 12:20:17 -0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id vB8CKHmw59506816; Fri, 8 Dec 2017 12:20:17 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 29864A405E; Fri, 8 Dec 2017 12:14:41 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1E277A4055; Fri, 8 Dec 2017 12:14:41 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.164.172.176]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 8 Dec 2017 12:14:41 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id B8336D8043A; Fri, 8 Dec 2017 13:20:16 +0100 (CET) Subject: Re: gdbarch_init, ABI, and registers To: tim@sifive.com (Tim Newsome) Date: Fri, 08 Dec 2017 12:20:00 -0000 From: "Ulrich Weigand" Cc: gdb@sourceware.org (gdb) In-Reply-To: from "Tim Newsome" at Dec 07, 2017 01:22:22 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17120812-0040-0000-0000-000003F7D3CB X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17120812-0041-0000-0000-000025FAD445 Message-Id: <20171208122016.B8336D8043A@oc3748833570.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-08_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712080174 X-SW-Source: 2017-12/txt/msg00010.txt.bz2 Tim Newsome wrote: > I've made some progress here. > > gdb does keep track of the description for the current target, and it can > be retrieved by calling target_current_description(). My problems stemmed > from the fact that sometimes riscv_gdbarch_init() was called with an info > structure that did not have the current target description filled out. I > tracked this down to gdbarch_from_bfd(), which doesn't set > info.target_desc. set_gdbarch_from_file() does do so (since 2008), and the > following patch makes everything work for me: > > diff --git a/gdb/arch-utils.c b/gdb/arch-utils.c > index 2ae3413087..6c84f100af 100644 > --- a/gdb/arch-utils.c > +++ b/gdb/arch-utils.c > @@ -600,6 +600,7 @@ gdbarch_from_bfd (bfd *abfd) > gdbarch_info_init (&info); > > info.abfd =3D abfd; > + info.target_desc =3D target_current_description (); > return gdbarch_find_by_info (info); > } > > Does this seem like the right solution? A better one might be to put this > assignment in gdbarch_info_init(). Or I could just call > target_current_description() in riscv_arch_init() when no target > description is passed in. The latter goes against the comment accompanying > target_current_description(), but it would only be a target-dependent > change. 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. In particular, there are gdbarch objects that describe a *target* (i.e. an inferior GDB is operating on) -- those use target descriptions, and care about registers etc. But then there are also gdbarch objects that are used solely when looking at an *object file*, without involving any connection to a target -- those don't have target descriptions, and don't care about registers. The second type is generated by gdbarch_from_bfd, so those *should* not get any target description. This function can be called even when there is no target currently active at all. [ As an aside, it would probably be cleaner to actually use two different data structures for those different purposes in the first place. This hasn't been done yet, mostly because it would be a lot of effort to update all places where platform-specific gdbarch information is created ... ] 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? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com