From: Daniel Jacobowitz <drow@mv...> - 2002-03-14 02:30:08
On Thu, Mar 14, 2002 at 01:32:24AM +0000, John Levon wrote:
> On Wed, Mar 13, 2002 at 08:18:05PM -0500, Daniel Jacobowitz wrote:
> > Have you looked at the find_nearest_line code for stabs? It's in
> > bfd/syms.c. It reads the line numbers from function stabs into the
> > line table. The presence or absence of a matching line number marking
> > should be No Big Deal for this interface.
> Browsing the code, it looks like if I look up the very start of the
> function, and there's no entry at the given vma (so that :
> 1185 if (offset >= info->indextable[mid].val
> 1186 && offset < info->indextable[mid + 1].val)
> would catch it), then the above binary search will find the previous
> stab entry. So for example the first function in a file will come out as
> since *pline never gets set properly.
> And we've recently seen this problem with a user using 2.95.3.
> So either our definitions of Big Deal differ, or I'm just wrong and
> the problem we've been seeing is unrelated to what's being discussed
Both right again... the line information for the N_FUN stab is entered,
but then not used in the line number search. I believe this is simply
a bug in BFD. I'll test a patch later this week.
In other words, I don't believe this function needs the initial stab.
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
From: John Levon <levon@mo...> - 2002-03-18 14:09:47
On Sat, Mar 16, 2002 at 10:50:32PM -0500, Daniel Jacobowitz wrote:
> > Is the patch at the end of this message OK? John, does the patch work
> > for you?
with 2.12, gcc 2.95.3 compiled a.c, -g3 :
080483d8 1744754 45.3498 a /home/moz/a.c:0
080483c0 2102570 54.6502 b /home/moz/a.c:0
2.12 + your second patch :
080483d8 1797859 44.7118 a /home/moz/a.c:67
080483c0 2223136 55.2882 b /home/moz/a.c:50
Thanks for fixing this !
I am a complete moron for forgetting about endianness. May I be
forever marked as such.