This is the mail archive of the gdb-patches@sources.redhat.com 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: RFC: The Constructor Breakpoint Issue


David Lecomber <david@streamline-computing.com> writes:
> > You can't tell from the line table.  You can tell if you have both a
> > line table and a .debug_info section; in the case that is interesting
> > to you, the two PCs will be in different DW_TAG_subprogram trees.
> > Given the order in which we parse things I'm not sure if you'll be able
> > to check that easily.
> 
> How about this idea.. Getting into the dwarf2 area looks like quite a
> major set of mods, which ultimately will be supported only by the
> dwarves, which is not good.  However, inspection of the result of
> find_pc_function() suggests it is different on the occasions when it
> needs to be, such as in C++ constructors, and the same when we want it
> to be - such as the start and end of for loops.

What you're suggesting here, if I understand, is to take all the
occurrences of a given source line in the line table (and there may be
many, due not just to things like 'for' loops, but also due to
instruction scheduling and other sorts of optimizations), look to see
which function each falls in, and report the first occurrence from
each function.

Sounds good to me (although note that I don't approve symtab changes
any more, so this is just advice).  Some thoughts:

The line number lookup code actually looks for "best" matches, not
just exact matches; see symtab.c:find_line_common.  Preserving that
behavior will require a bit of care.

The downside that comes to mind is that this approach requires GDB to
always traverse the full linetable, instead of stopping as soon as it
finds an exact match, as it does now.

It'll be a substantial change to the line lookup machinery, since
those functions are not designed, at present, to return multiple
values.  But it's not that hairy in the aerial view.

There are some opportunities for optimization.  A symtab's linetable
and its blockvector's blocks are both sorted in order of increasing
addresses.  So one could traverse the blockvector and linetable in
parallel (skipping blocks that don't represent functions), and avoid
doing a full symbol lookup by pc for each plausible line.


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