From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3104 invoked by alias); 23 Sep 2006 00:28:14 -0000 Received: (qmail 3092 invoked by uid 22791); 23 Sep 2006 00:28:13 -0000 X-Spam-Check-By: sourceware.org Received: from hq.tensilica.com (HELO mailapp.tensilica.com) (65.205.227.29) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 23 Sep 2006 00:28:08 +0000 Received: from localhost ([127.0.0.1] ident=amavis) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1GQvNE-0003uM-KO; Fri, 22 Sep 2006 17:28:04 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13934-02; Fri, 22 Sep 2006 17:28:04 -0700 (PDT) Received: from maxim_fc3.hq.tensilica.com ([192.168.11.68]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1GQvNE-0003uG-85; Fri, 22 Sep 2006 17:28:04 -0700 Message-ID: <45147F94.4020701@hq.tensilica.com> Date: Sat, 23 Sep 2006 00:28:00 -0000 From: Maxim Grigoriev User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: gdb@sourceware.org, Daniel Jacobowitz , Marc Gauthier , Bob Wilson Subject: Re: Xtensa port References: <45142A88.7000805@hq.tensilica.com> <20060922190726.GA8221@nevyn.them.org> In-Reply-To: <20060922190726.GA8221@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00136.txt.bz2 Hi Daniel, I hope I know how to handle all your other comments. But, this one is not easy: >> +/* get_fp_num() returns the register number of the frame pointer for the frame >> + specified by pc. Depending on how the function was compiled, the fp could >> + be either a1 (sp) or another register set by the compiler. >> + Note: it returns register number for an Ax, not for ARx. >> + >> + We extract the FP register number from the DWARF info generated by the >> + compiler. If anything is wrong with the DWARF info or there is no DWARF >> + info at all we return A1_REGNUM. */ >> + >> +static int >> +get_fp_num (CORE_ADDR pc) >> +{ >> + struct symtab_and_line debug_info; >> + struct symbol *func_sym; >> + >> + DEBUGTRACE ("get_fp_num (pc = 0x%08x)\n", (int) pc); >> + >> + debug_info = find_pc_line (pc, 0); >> + /* If there is no debug info return A1. */ >> + if (debug_info.line == 0) >> + return A1_REGNUM; >> + >> + func_sym = find_pc_function (pc); >> + if (func_sym) >> + { >> + if (SYMBOL_OPS (func_sym) == &dwarf2_locexpr_funcs) >> > > No way. I don't know what you need this information for, but we have > to find some way to get it that does not require grubbing around in the > private data structures of the symbol reader I need an FP number. And, the most reliable source for this information is DWARF data. When GDB generates offsets and addresses for, say, local variables, it uses exactly the same technique I used here. But, it's done in a specific context, which is not available in xtensa-tdep.c. I was not able to find a clear "utility" routine to get an FP number for a given function. So I just implemented it. Can you give me some hints on how could it be done differently, please ? If there is no such "utility" request ( which I thought is the case ), I'd need to introduce it. That would be an update to the generic part of GDB. And, I was given specific instructions to avoid any updates to the generic code, when I submit an architecture port. -- Maxim