From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16807 invoked by alias); 3 Jan 2003 00:28:37 -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 16779 invoked from network); 3 Jan 2003 00:28:33 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by 209.249.29.67 with SMTP; 3 Jan 2003 00:28:33 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id BDFFD3DE5; Fri, 3 Jan 2003 00:28:10 +0000 (GMT) Message-ID: <3E14D919.1040704@redhat.com> Date: Fri, 03 Jan 2003 00:28:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.1) Gecko/20021211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Michal Ludvig , GDB Patches Subject: Re: [RFA] Artifical dwarf2 debug info References: <3DFE3007.3040100@redhat.com> <20021216201117.GA31474@nevyn.them.org> <3DFF185B.9090806@suse.cz> <3DFF3353.2090803@redhat.com> <20021217151304.GA5778@nevyn.them.org> <3E0057EB.1080104@redhat.com> <20021218153733.GA11738@nevyn.them.org> <3E14A709.9040902@redhat.com> <20030102211836.GA23173@nevyn.them.org> <3E14C5C1.5060100@redhat.com> <20030102232702.GA5093@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00044.txt.bz2 >> Right. That gets removed. Instead that info gets passed to the CFI >> code as a `parameter' (perhaphs explicitly, or perhaps implicitly as >> part of a member of the CONTEXT object). > > > This I don't get at all. Why? What advantage is there? Whose > business besides the CFI reader's is it whether or not there is an FDE? The logic that makes the decision to use dwarf2 cfi, the dwarf2 like unwind code, or this artificial info, or even the old style saved-regs. That logic lives in get_prev_frame(). Why should the dwarf2 unwind et.al. code assume that the info it needs is comming from the dwarf2 reader? I thought the point of the change was that the dwarf2 cfi reader from all the code that uses that information - hence allowing us to fake up dwarf2 info. >> The latter can be further broken down into: >> >> dwarf2 fde / cfi frames >> saved-register frames >> artifical fde / cfi frames >> ... > > > I still don't see the point of this distinction. What differentiates a > saved-register frame from a dwarf2 fde / cfi frame, anyway? There are > saved registers; we figure out where they are via CFI. A saved-registers frame uses the existing code (frame->saved_regs) to locate a saved register. It doesn't read dwarf2 debug info and then use that to do CFI. CFI is just one of a number of ways to unwind a normal frame. >> >Maybe there will be others, but notice that all the above are >> >conceptually different kinds of things. These "artifical" frames are >> >just normal frames, where we synthesize the debug information because >> >we didn't have any. It's a mechanism to coalesce things like prologue >> >readers. It is absolutely not a new type of frame. >> > >> >That's why I think this code is in exactly the right place, right now. >> >Are you saying that the CFI code should just be returning, saying "no >> >idea, go away, don't talk to me", and leaving this be? > >> >> Why was the dwarf2cfi code even called? Since there is no dwarf2 cfi >> that code path should not have been reached. Per my comment below, this >> would have happend because the caller (or something up the stack) failed >> to check for an edge condition. That change is patching things up after >> the event. >> >> Instead, during `struct frame_info' creation, if there isn't any dwarf2 >> info, and the architecture really wants to use the dwarf2cfi logic, it >> should create an `artifical fde / cfi frame' that first fakes up the FDE >> info and then supplies that to the dwarf2cfi logic. Similarly, a dwarf2 >> cfi frame can first read the fde and then call the relevant code. > > > It sounds to me as if you want to move the call to the frame creation > logic somewhere else and that's it. The place you want to move it > doesn't exist yet, as far as I can tell. Am I right? The `struct frame_info' creation logic lives in frame.c - see get_prev_frame(). It hasn't moved but is being expanded. Only problem is with the x86-64. That code is trying to locally handle cases that are better handled by get_prev_frame(). Again, note all those pc_in_call_dummy() et.al. tests? >> > That's all well >> > and good but that way we end up duplicating the whole of the CFI >> > reader. A good long term direction, with appropriate code factoring, >> > but it's hardly practical. > >> >> How does this result in the duplication of the CFI reader? > > > The entire CFA program execution and unwind logic would be exactly > identical to that of the "artificial frame" case. And hence wouldn't / shouldn't be duplicated. >> >>This is part of a long standing problem - it predates dwarf2cf by many >> >>years. Instead of using recursion, people modify debug/target dependent >> >>frame code so that it attempts to directly handle all cases. Cf all the >> >>PC_IN_CALL_DUMMY(frame->next), PC_IN_SIGTRAMP(frame->next) and other >> >>tests scattered through out the -tdep.c code; and the calls to >> >>get_next_frame() in dwarf2cfi.c. > >> > >> > >> >The one call to get_next_frame, which parallels init_frame_pc_default. > >> >> Right. And init_frame_pc_default() is, again, typical of the problem. >> It shouldn't need to refer to frame->next. > > > I can't claim to understand how that would work. Separate functions would handle separate cases. Andrew