Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: drow@false.org, gdb-patches@sourceware.org
Subject: Re: [RFA] Fix "break foo" when `foo's prologue ends before line	table
Date: Tue, 12 May 2009 03:09:00 -0000	[thread overview]
Message-ID: <83skjbxbje.fsf@gnu.org> (raw)
In-Reply-To: <20090511211855.GA7584@adacore.com>

> Date: Mon, 11 May 2009 23:18:55 +0200
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Daniel Jacobowitz <drow@false.org>, gdb-patches@sourceware.org
> 
> > 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.
> 
> You should be able to find another confirmation of this by looking
> at the .s file.  I don't know what assembler directive is used on
> DJGPP to emit lines, but it's usually straightforward.

DJGPP uses gas, so the directives are the same as on GNU/Linux.

Do we still need more confirmations that the COFF info indeed lacks
line information for the opening brace, given the objdump output I
posted?

> > > 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.
> 
> I don't think it matters what the code does, since otherwise you
> would skip that code before inserting the breakpoint anyway.
> 
> > Even if we could, is that really better than the approach I suggested?
> 
> Not sure if this is better or not. The advantage of this approach is
> that we protect other platforms from this form of debugging info -
> one could argue that it's incomplete.

Maybe it is, but knowing it's incomplete and completing it correctly
are two different things.  For starters, what line number could we
possibly add to the additional entry?  The only safe possibility would
be the same line as in some existing lineinfo entry whose line number
is the smallest one.  But that would mean "info line" could now
produce potentially incorrect or misleading information, couldn't it?


      reply	other threads:[~2009-05-12  3:09 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
2009-05-11 21:19     ` Joel Brobecker
2009-05-12  3:09       ` Eli Zaretskii [this message]

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=83skjbxbje.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=brobecker@adacore.com \
    --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