From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-78020-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 10306 invoked by alias); 4 Feb 2011 18:43:32 -0000
Received: (qmail 10297 invoked by uid 22791); 4 Feb 2011 18:43:31 -0000
X-SWARE-Spam-Status: No, hits=-0.9 required=5.0	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from mail.apical.co.uk (HELO srv1.office.apical.co.uk) (213.106.251.44)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 Feb 2011 18:43:27 +0000
Received: from [10.250.148.115] (23.nat.acronis.net [91.195.22.23])	(authenticated bits=0)	by srv1.office.apical.co.uk (8.14.4/8.14.4) with ESMTP id p14IhDJl027530	(version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO);	Fri, 4 Feb 2011 18:43:14 GMT
Message-ID: <4D4C4576.2020709@sw.ru>
Date: Fri, 04 Feb 2011 18:43:00 -0000
From: Vladimir Simonov <sv@sw.ru>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc11 Thunderbird/3.0.4
MIME-Version: 1.0
To: Tom Tromey <tromey@redhat.com>
CC: gdb-patches@sourceware.org
Subject: Re: gdb: Incorrect stack unwinding if compressed debug info is used
References: <1296238472.3009.ezmlm@sourceware.org> <4D46D872.6080407@sw.ru>	<m3y65vahdf.fsf@fleche.redhat.com> <4D4C383A.3000203@sw.ru> <m3mxmb8z0c.fsf@fleche.redhat.com>
In-Reply-To: <m3mxmb8z0c.fsf@fleche.redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2011-02/txt/msg00087.txt.bz2

On 02/04/2011 08:56 PM, Tom Tromey wrote:

>
> So, I came up with the appended.  Let me know what you think.  If you
> could try it, that would be helpful.
>
This one works fine on my test also.

The only I can mention - the name
dwarf2_section_size a bit misleading, it hides
the fact that it will read section if it is not done.
May be just change dwarf2_read_section to return
size?

Also I'm not sure that call functions inside "if"
are encouraged in gdb coding style. I mean
+  if (header->abbrev_offset
+      >= dwarf2_section_size (dwarf2_per_objfile->objfile,
+			      &dwarf2_per_objfile->abbrev))
etc.


Regards
Vladimir