From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15977 invoked by alias); 11 Nov 2005 00:10:24 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 15954 invoked by uid 22791); 11 Nov 2005 00:10:20 -0000 Received: from s142-179-108-108.bc.hsia.telus.net (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 11 Nov 2005 00:10:20 +0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id D341447E79; Thu, 10 Nov 2005 16:10:17 -0800 (PST) Date: Fri, 11 Nov 2005 11:22:00 -0000 From: Joel Brobecker To: Randolph Chung Cc: gdb-patches@sources.redhat.com Subject: Re: [hppa] FYI: confusion in unwind descriptor field meaning Message-ID: <20051111001017.GJ1635@adacore.com> References: <20051109203108.GX1635@adacore.com> <43735815.3070805@tausq.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43735815.3070805@tausq.org> User-Agent: Mutt/1.4i X-SW-Source: 2005-11/txt/msg00142.txt.bz2 Hey Randolph, [regarding Save_SP and Large_frame] I think I'm starting to slowly get the big picture. Obviously not as simple as I thought. On top of that, GNAT Pro has some internal modifications in that area, and I'm still trying to create the list of such modifications. The expert in the company lives in France but tomorrow is a holiday, so I'll have to wait for monday to get some answers. > >So I think the following test is wrong: > > > > /* Handle code with and without frame pointers. */ > > if (u->Save_SP) > > cache->saved_regs[reg].addr = offset; > > else > > cache->saved_regs[reg].addr = (u->Total_frame_size << 3) + offset; > > > >I think it should read something like: > > > > if (u->Large_frame) > > > >or something like this. Or perhaps we should check the base register > >and if it is r3, then only use the offset. Not sure yet. > > I don't know if you are trying to tackle any specific problem you have > observed, but the current code works for gcc. I'm starting to understand why. The bug I was working on came from code provided to our customer by Oracle. It seems that code was built using the HP compiler, as opposed to GCC. Given David and your feedback regarding these two flags, it looks like the above can be safely modified into (u->save_SP || u->Large_frame). Not a big worry for me at the moment, though. > Yes, I have seen this under hppa-linux for some hand coded asm functions > too. This is not important to this debate, but I'd be interested in seeing the asm, to see how you can create unwind records saying that the region has no entry/exit point. > It still does, and the fact is that the current unwinder code has > evolved through many rounds of testing under hppa-linux. We still have a > large number of testsuite failures under HPUX that really need to be > investigated. The tricky part is that not only does gcc not follow the > ABI precisely, iirc even the HP tools don't always follow the > documentation precisely in some places. I think the only realistic thing > to do is to empirically examine code that is not working and try to fix > gdb to handle it. I agree with you that the current unwinder can use > some cleaning up; unfortunately it is also rather fragile and subtle. > I've tried to document interesting things I've found along the way, but > the unwind data just isn't always very precisely describing what is > happening in the prologue. After your feedback, I'm starting to think that this whole unwind record thing is a wasp nest. This is loud thinking at this stage, but let me suggest something heretical: How about to stop using the unwind record to do the unwinding? We scan the prologue as we've always done, and collect all the information, including the fact that the function has a frame pointer or not. Then we don't need use the unwind record, except maybe to determine the function start address. I think we might even be able to dump the FP_REGNUM entirely. The good thing is that I don't think we'll need that many changes to the code to get to that point. Improve a bit the code scanner to retrieve the information that we normally dig out of the unwind record, and we should have something at least marginally working. The other advantage is that now the debugger doesn't need to know what compiler produced the object. So I'll be able to share the changes we make internally too. What do you think? Long term: There was a patch recently posted about a finite-state machine system that could be used to do prologue analysis in a simpler and more mechanical way. There have been some design suggestions made, so it's going to be a while before it becomes available. But this is a logical extension of the idea above. Here is what I suggest: I can't promise that I'll have time for this, as AdaCore is going to start preparing a new release of GNAT Pro at the end of this year, and I still have a bit of work to get ready for this. But I would like to continue collecting all the information you have provided me, plus some info about our own changes, stir it with the experience I've developped in the past year fixing bugs on this platform, and try this new idea of dumping the unwind record. I will try first with our debugger, so that I can try the debugger with our compiler too. But I'll send patches as I make progress. > Dave has been working on adding dwarf2 support to gcc for both linux and > hpux targets; perhaps one day we can rely on dwarf for better debugging. That would be a very good improvement indeed, but would still leave us with the problem of non-GCC compiled code, as well as system libraries. -- Joel