From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22932 invoked by alias); 28 Mar 2002 23:03:05 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22925 invoked from network); 28 Mar 2002 23:03:04 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 28 Mar 2002 23:03:04 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8E8AE3DB3; Thu, 28 Mar 2002 18:01:18 -0500 (EST) Message-ID: <3CA3A0BE.1000908@cygnus.com> Date: Thu, 28 Mar 2002 15:03:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.8) Gecko/20020210 X-Accept-Language: en-us MIME-Version: 1.0 To: Jim Blandy Cc: Daniel Berlin , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-03/txt/msg00590.txt.bz2 > > I spoke with Andrew on the phone yesterday, and he and I have > different ideas about how things should go. I don't think I > understood the path of changes he wanted to see. (Tuesday .CA) The bulk of the discussion was about: http://sources.redhat.com/ml/gdb/2002-03/msg00154.html and its implications. However, implementation details on the bit of code below did come up. From memory JimB was proposing that the code be in two parts: a completly separate 100% parameterized engine; a wrapper function s(one for CFI one for Dan's needs). I was more for a single function and a ``struct frame_info *'' parameter. Given I'm not likely to be the one implementing it, it probably doesn't matter to me :-) > My personal inclination is to make the Dwarf 2 location expression > interpreter as independent from GDB as possible. It can use the > CORE_ADDR type for stack elements, but it should take arguments > specifying: > - the expression as a simple char * pointer and length, > - the architecture's address size, > - function pointers for reading memory and registers that simply hand > back a CORE_ADDR value (thus keeping the interpreter innocent of > endianness issues), and > - the frame base address (for DW_OP_fbreg) I suspect a function call here might be a good idea as well - to ensure that the value isn't used when it hasn't been computed or to delay its computation. Andrew