This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Fix "break foo" when `foo's prologue ends before line table


> 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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]