From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28646 invoked by alias); 8 Dec 2017 16:57:11 -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 28636 invoked by uid 89); 8 Dec 2017 16:57:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1170 X-HELO: mail-qt0-f174.google.com Received: from mail-qt0-f174.google.com (HELO mail-qt0-f174.google.com) (209.85.216.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Dec 2017 16:57:09 +0000 Received: by mail-qt0-f174.google.com with SMTP id e2so27408294qti.0 for ; Fri, 08 Dec 2017 08:57:09 -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:content-transfer-encoding; bh=Kk8ymxzQDj7HnHWXnV4G4ePIR7AnOmyJa551Z8bgadc=; b=oY5ulykd0ozOrzI5ICY7bYiMyPz+0MskvgE7vQt9EoBNiEC0/CrO68uem5TXopNTWq qILRbMlQBBemIgoSlHt9Atl2CUVTg2I8eNW+WgaPJsCBBywbGGvYgr8LuIrl6fcVO1rz LBlwk/0kIJF9z9Q2RLiaa87P2ihC1IyRy+ajtLmdVk29mYgO43bcnrQfs6l2JO7YLPwT +pO5azErVnLzIcyz7MlcHbK/53Yuvx5hcGRO/i+1XlSjMQHJ4wAuGyy7ZQI0CTi0em+6 Mvnmq7mNwdxR0MAZNC+1mmSLF8Odxbawpjw1GpgfTbEdRqgSRjVhHDYoITeq2HPqJ/sa wvNQ== X-Gm-Message-State: AKGB3mINN28fDPHdeKww4Z/YWXg3AlFxX2DHKRdgeLxnFFbIDPkWHXYN BpToFYBiFQwiB5Awwa8CvRop5ViqnveCJp900KEQOw== X-Google-Smtp-Source: AGs4zMZW3sLNn+njH5sfHNV24GespnPPeJRFzRB98AF05X668sPFWe4zpB0/q1cniOSF0YBcpGqwjqlaKBge+3J27QY= X-Received: by 10.200.50.39 with SMTP id x36mr18150813qta.255.1512752227974; Fri, 08 Dec 2017 08:57:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.132.161 with HTTP; Fri, 8 Dec 2017 08:57:07 -0800 (PST) In-Reply-To: <19d93119-75cb-435c-9ddb-1f42f6ac8e69@redhat.com> References: <20171126163756.1515ED802F9@oc3748833570.ibm.com> <0bea6805-b8eb-da2c-07f6-0f1ee917c7b5@redhat.com> <867etxpn9k.fsf@gmail.com> <19d93119-75cb-435c-9ddb-1f42f6ac8e69@redhat.com> From: Yao Qi Date: Fri, 08 Dec 2017 16:57:00 -0000 Message-ID: Subject: Re: [PATCH] Fix setting-breakpoints regression on PPC64 (function descriptors) To: Pedro Alves Cc: Ulrich Weigand , Jan Kratochvil , Simon Marchi , Keith Seitz , GDB Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00191.txt.bz2 On Fri, Dec 8, 2017 at 11:34 AM, Pedro Alves wrote: > That's fine with me. I guess we end up with the wrong section > in the function descriptor / PPC64 case (".opd" instead of some kind > of ".text" where the resolved function lives), but it shouldn't > matter, since the old code did that as well, AFAICT. I tested the patch on gcc110, there is no regression. I pushed it in. > > (I noticed that get_sal_arch doesn't consider sal.objfile, probably > because it predates addition of the 'obfile' field. We could probably > fill in / use that field more, but we don't need to do that now.) I noticed that too, but one thing I am not sure is that sal.objfile is *only* used for probe, /* The probe associated with this symtab_and_line. */ probe *prob =3D NULL; /* If PROBE is not NULL, then this is the objfile in which the probe originated. */ struct objfile *objfile =3D NULL; so can we use it in other cases (when probe is not used)? I don't know. If so, are sal.objfile and sal.section->objfile different or same? I need to look at the code there. --=20 Yao (=E9=BD=90=E5=B0=A7)