Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA] Fix "break foo" when `foo's prologue ends before line	table
Date: Mon, 11 May 2009 20:40:00 -0000	[thread overview]
Message-ID: <83vdo7xtk1.fsf@gnu.org> (raw)
In-Reply-To: <20090511194247.GA9877@caradoc.them.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.


  reply	other threads:[~2009-05-11 20:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-09 14:26 Eli Zaretskii
2009-05-11 12:56 ` Joel Brobecker
2009-05-11 18:21   ` Eli Zaretskii
2009-05-11 19:27     ` Joel Brobecker
2009-05-11 20:49       ` Eli Zaretskii
2009-05-11 21:20         ` Daniel Jacobowitz
2009-05-12  3:13           ` Eli Zaretskii
2009-05-11 21:28         ` Joel Brobecker
2009-05-16 11:18         ` Eli Zaretskii
2009-05-20 23:07           ` Joel Brobecker
2009-05-23 10:20             ` Eli Zaretskii
2009-05-25  7:26               ` Joel Brobecker
2009-05-11 19:42 ` Daniel Jacobowitz
2009-05-11 20:40   ` Eli Zaretskii [this message]
2009-05-11 21:19     ` Joel Brobecker
2009-05-12  3:09       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83vdo7xtk1.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox