From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1651 invoked by alias); 20 May 2008 15:32:49 -0000 Received: (qmail 1643 invoked by uid 22791); 20 May 2008 15:32:48 -0000 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.31) with ESMTP; Tue, 20 May 2008 15:32:27 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id m4KFWOG9146322 for ; Tue, 20 May 2008 15:32:24 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 v8.7) with ESMTP id m4KFWORW2449424 for ; Tue, 20 May 2008 17:32:24 +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 m4KFWN7F021491 for ; Tue, 20 May 2008 17:32:23 +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 m4KFWNcS021488; Tue, 20 May 2008 17:32:23 +0200 Message-Id: <200805201532.m4KFWNcS021488@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 20 May 2008 17:32:23 +0200 Subject: Re: [patch] Get rid of current_gdbarch in xtensa To: deuling@de.ibm.com (Markus Deuling), maxim2405@gmail.com Date: Tue, 20 May 2008 18:08:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org (GDB Patches) In-Reply-To: <4830FF13.4070605@de.ibm.com> from "Markus Deuling" at May 19, 2008 06:16:19 AM X-Mailer: ELM [version 2.5 PL2] 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: 2008-05/txt/msg00598.txt.bz2 Markus Deuling wrote: > @@ -2034,9 +2034,9 @@ call0_track_op (xtensa_c0reg_t dst[], xt > /* 2 operands: dst, literal offset. */ > gdb_assert (nods == 2); > /* litbase = xtensa_get_litbase (pc); can be also used. */ > - litbase = (gdbarch_tdep (current_gdbarch)->litbase_regnum == -1) > + litbase = (gdbarch_tdep (gdbarch)->litbase_regnum == -1) > ? 0 : xtensa_read_register > - (gdbarch_tdep (current_gdbarch)->litbase_regnum); > + (gdbarch_tdep (gdbarch)->litbase_regnum); There's really a different problem here: xtensa_read_register simply uses get_current_regcache () to retrieve that "litbase" register. This seems quite broken, in particular when call0_track_op is called out of the xtensa_skip_prologue code path, where the current regcache may not really be related at all to the function that is being queried ... In those cases where we have a proper frame to read from, the question of how to retrieve the litbase register number should resolve itself automatically. Maxim, do you have any suggestions how to handle this? Is there a way to retrieve the "litbase" in the xtensa_skip_prologue case? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com