From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6666 invoked by alias); 10 Nov 2005 14:24:41 -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 6438 invoked by uid 22791); 10 Nov 2005 14:24:35 -0000 Received: from ip127.bb146.pacific.net.hk (HELO stl.com.hk) (202.64.146.127) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 10 Nov 2005 14:24:35 +0000 Received: from 86.194.17.210.dyn.pacific.net.hk ([210.17.194.86] helo=[192.168.1.10]) by stl.com.hk with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EaDJB-0008PZ-8H; Thu, 10 Nov 2005 22:21:45 +0800 Message-ID: <43735815.3070805@tausq.org> Date: Thu, 10 Nov 2005 19:18:00 -0000 From: Randolph Chung User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) MIME-Version: 1.0 To: Joel Brobecker CC: gdb-patches@sources.redhat.com Subject: Re: [hppa] FYI: confusion in unwind descriptor field meaning References: <20051109203108.GX1635@adacore.com> In-Reply-To: <20051109203108.GX1635@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-11/txt/msg00135.txt.bz2 ok, some more comments: > This is something I'm still working on, so I haven't verified my theory > just yet. But I think there is a confusion in the meaning of Save_SP > in the unwind descriptor. The document I have says: > > 18. Save_SP (bit 27): One if the entry value of SP is saved by this > regions entry sequence in the current frame marker (current_SP - 4); > zero otherwise. > > It doesn't say that the frame has a frame base register. For this, we > have another field: gcc uses this to mean that the frame base has been saved to the stack. > 25. Large_frame_r3 (bit 34): One if gr3 is changed during the entry > sequence to contain the address of the base of the (new) frame. but it doesn't use this. This seems to be related to alloca? > 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. > The problem I'm really working on is not affected by the above, it's > more about finding out that the function, although the Alloca flag is > not set, has a variable-size frame. I need to use the Large_frame flag > to determine that we have a frame base, and therfore use r3 as the frame > base if the previous_SP has been saved there. Which compiler? gcc doesn't use the Large_frame_r3 flag, but HP compilers might, and if you have a tool that needs to use this flag, and it follows the documentation, perhaps we can support this *in addition to the current constructs* in gdb. > Generally speaking, there have been fixing a large number of issues our > customers have helped us find out. For instance, we have found code > pieces where the unwind record shows a discontinuous region: No entry > point. So the address start of the region does not point at the function > start and hence no prologue, with the consequences you can imagine when > we scan that region looking for prologue instructions... Yes, I have seen this under hppa-linux for some hand coded asm functions too. > Unfortunately, I'm unable to contribute either the examples provided > by the customer (they often come in the form of a gigantic executable > along with a core file, no source), nor the fix, because the compiler > we use made some tweaks to the unwind data so that the HP unwinder is > able to unwind through GCC code as well as HP code (I understand GCC > made some small deviations from the ABI, or used to make maybe). 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. 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. randolph