This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Fix "break foo" when `foo's prologue ends before line table
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 11 May 2009 23:39:58 +0300
- Subject: Re: [RFA] Fix "break foo" when `foo's prologue ends before line table
- References: <83skjebbef.fsf@gnu.org> <20090511194247.GA9877@caradoc.them.org>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Mon, 11 May 2009 15:42:47 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 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.