From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6869 invoked by alias); 16 Mar 2011 06:07:14 -0000 Received: (qmail 6861 invoked by uid 22791); 16 Mar 2011 06:07:13 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Mar 2011 06:07:03 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p2G672UI001597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 16 Mar 2011 02:07:02 -0400 Received: from host1.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p2G670UM016198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2011 02:07:01 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p2G66xVY032287; Wed, 16 Mar 2011 07:06:59 +0100 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p2G66w0O032226; Wed, 16 Mar 2011 07:06:58 +0100 Date: Wed, 16 Mar 2011 08:20:00 -0000 From: Jan Kratochvil To: Paul Pluzhnikov Cc: Tom Tromey , gdb-patches ml , Doug Evans Subject: Re: [patch] Re: Advice on fixing gdb/12528 Message-ID: <20110316060658.GA10163@host1.jankratochvil.net> References: <20110315004140.GA28560@host1.jankratochvil.net> <20110315183650.GA29330@host1.jankratochvil.net> <20110315190304.GA784@host1.jankratochvil.net> <20110315212428.GA21487@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00832.txt.bz2 On Tue, 15 Mar 2011 22:45:02 +0100, Paul Pluzhnikov wrote: > On Tue, Mar 15, 2011 at 2:24 PM, Jan Kratochvil wrote: > >                      complaint (&symfile_complaints, > >                                 _(".debug_line offset 0x%lx uses address 0 " > >                                   "[in module %s]"), > >                                 (long) (line_ptr > >                                         - dwarf2_per_objfile->line.buffer), > >                                 cu->objfile->name); > > > > (the offset is not right but better than nothing) > > Maybe like this: > > if (address == 0 && !dwarf2_per_objfile->has_section_at_zero) > { > /* This line table is for a function which has been > GCd by the linker. Ignore it. PR gdb/12528 */ > > long line_offset > = line_ptr - bytes_read - dwarf2_per_objfile->line.buffer; > > complaint (&symfile_complaints, > _(".debug_line offset 0x%lx uses address 0 " > "[in module %s]"), > line_offset, cu->objfile->name); > p_record_line = noop_record_line; > } BYTES_READ is here just for the ADDRESS size. One can also subtract 1 for EXTENDED_OP read in, subtract already overwritten BYTES_READ for EXTENDED_LEN read in and subtract 1 for OP_CODE read in. This way we get the offset where this operation starts. But neither binutils nor elfutils readelf display offsets of the .debug_line operations so one cannot debug the resulting offset so much which is why I thought some approx. offset is good enough. I do not think the displayed offset is so importatnt but at least the module gets shown. Thanks, Jan