From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27467 invoked by alias); 8 Jun 2009 14:53:39 -0000 Received: (qmail 27453 invoked by uid 22791); 8 Jun 2009 14:53:38 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.29.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 08 Jun 2009 14:53:31 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.14.3/8.13.8) with ESMTP id n58ErQVX215984 for ; Mon, 8 Jun 2009 14:53:26 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n58ErPtY3375164 for ; Mon, 8 Jun 2009 16:53:25 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n58ErOqC012267 for ; Mon, 8 Jun 2009 16:53:25 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id n58ErNWT012241; Mon, 8 Jun 2009 16:53:23 +0200 Message-Id: <200906081453.n58ErNWT012241@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 08 Jun 2009 16:53:23 +0200 Subject: Re: [10/19] record_line To: eliz@gnu.org Date: Mon, 08 Jun 2009 14:53:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: from "Eli Zaretskii" at Jun 05, 2009 09:14:59 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00178.txt.bz2 Eli Zaretskii wrote: > > Date: Fri, 5 Jun 2009 23:18:16 +0200 (CEST) > > From: "Ulrich Weigand" > > > > the record_line routine calls gdbarch_addr_bits_remove on the PC it is > > passed. As there is no appropriate objfile at hand in this routine, > > the following patch moves this operation up into the callers of record_line, > > which will use the objfile architecture of the file they are processing. > > Maybe I'm missing something, but isn't this rather inelegant? We are > moving some detail that is private to record_line into its callers, > just because record_line doesn't know the architecture nor the objfile > to get the architecture from? Why not simply pass the architecture or > the objfile to record_line instead? Well, I guess I didn't really express this in the patch email, but it seemed to me that calling gdbarch_addr_bits_remove should't really be a private detail of record_line. IMO this routine should simply take an actual PC as input, as its comment states -- whatever hacks are required to compute an actual PC value from information found in the object file should be done in the symbol readers themselves (this might actually depend on the format). For the purposes of this patch series, passing an objfile in to record_line would work for me as well. It just didn't seem quite the right thing .. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com