From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9127 invoked by alias); 6 Jun 2009 01:15:13 -0000 Received: (qmail 9117 invoked by uid 22791); 6 Jun 2009 01:15:12 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 06 Jun 2009 01:15:05 +0000 Received: from eliz by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MCkUt-0000zi-Ml; Fri, 05 Jun 2009 21:14:59 -0400 From: Eli Zaretskii To: "Ulrich Weigand" CC: gdb-patches@sourceware.org In-reply-to: <200906052118.n55LIGmw029014@d12av02.megacenter.de.ibm.com> (uweigand@de.ibm.com) Subject: Re: [10/19] record_line Reply-to: Eli Zaretskii References: <200906052118.n55LIGmw029014@d12av02.megacenter.de.ibm.com> Message-Id: Date: Sat, 06 Jun 2009 01:15:00 -0000 X-IsSubscribed: yes 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/msg00149.txt.bz2 > 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?