From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16113 invoked by alias); 11 May 2009 20:40:08 -0000 Received: (qmail 16101 invoked by uid 22791); 11 May 2009 20:40:06 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout4.012.net.il (HELO mtaout3.012.net.il) (84.95.2.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 May 2009 20:39:59 +0000 Received: from conversion-daemon.i_mtaout3.012.net.il by i_mtaout3.012.net.il (HyperSendmail v2004.12) id <0KJH00D00YMNWI00@i_mtaout3.012.net.il> for gdb-patches@sourceware.org; Mon, 11 May 2009 23:39:56 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.228.73.80]) by i_mtaout3.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KJH00GKJYQJVUZ0@i_mtaout3.012.net.il>; Mon, 11 May 2009 23:39:56 +0300 (IDT) Date: Mon, 11 May 2009 20:40:00 -0000 From: Eli Zaretskii Subject: Re: [RFA] Fix "break foo" when `foo's prologue ends before line table In-reply-to: <20090511194247.GA9877@caradoc.them.org> To: Daniel Jacobowitz Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83vdo7xtk1.fsf@gnu.org> References: <83skjebbef.fsf@gnu.org> <20090511194247.GA9877@caradoc.them.org> 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: 2009-05/txt/msg00226.txt.bz2 > Date: Mon, 11 May 2009 15:42:47 -0400 > From: Daniel Jacobowitz > Cc: gdb-patches@sourceware.org > > On Sat, May 09, 2009 at 05:26:16PM +0300, Eli Zaretskii wrote: > > Note that the lineinfo table for the program starts at line 6 at PC > > 0x1748, whereas the function `main' begins at PC 0x172c. > > Is this really what the coff file says? I would think so. What I show in my mail comes from "maint print symbols", so I have no reason to believe the lineinfo table does not reflect the COFF debug info. Here's the relevant part of "objdump -t", as another data point: [ 56](sec 1)(fl 0x00)(ty 24)(scl 2) (nx 1) 0x0000172c _main AUX tagndx 0 ttlsiz 0x56 lnnos 66672 next 64 _main : 2 : 00001748 4 : 00001750 5 : 00001756 7 : 0000176b 9 : 0000177b 10 : 00001780 [ 58](sec 1)(fl 0x00)(ty 0)(scl 101) (nx 1) 0x0000172c .bf AUX lnno 5 size 0x0 tagndx 0 > If so, it is a bug in GCC. If we're at 0x172c, GDB should be able > to show which line we're on, and we're definitely on some line of > main. Maybe. But the lines before that are just decorations, from the source code POV, they are not function body. The code generated by them is actually the prologue, isn't it? > Is it possible to patch this up in the coff line table reader? What, by inventing extra entries in the table? That could be dangerous, since we would be doing that without any clear idea of the code between 0x172c and 0x1748. Even if we could, is that really better than the approach I suggested? We already skip the prologue when looking for the first line of the function's body, even before looking in the lineinfo table; what I suggest simply uses yet another possible definition of that first line, when the other definitions fail.