This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB <MULTIPLE> breakpoints, source lines
On Sat, 2009-02-14 at 13:22 +0300, Vladimir Prus wrote:
> Peter Wainwright wrote:
>
> > Hi,
> >
> > I'm the maintainer of DDD. I have some questions about the intent of
> > the gdb <MULTIPLE> breakpoints.
> >
> > "info break" returns several lines for each breakpoint, e.g.
> >
> > 2.1 y 0x00007f2e2090c4d4 in
> > VoxelBuffer<char>::buffer_type() const
> > at ../VoxelBuffer.cc:95
> > 2.2 y 0x00007f2e2090c540 in
> > VoxelBuffer<unsigned char>::buffer_type() const at ../VoxelBuffer.cc:95
> > 2.3 y 0x00007f2e2090c5ac in
> > VoxelBuffer<short>::buffer_type() const
> > at ../VoxelBuffer.cc:95
> >
> > The info page on breakpoints mentions 3 use cases: constructors,
> > templates, and inlined functions. In all 3 cases the multiple locations
> > are generated from a single source line. However, the "info break"
> > display shows a source file and line number for each location.
> >
> > My question is: are there any circumstances in which you can get a
> > different source file or line for each location?
>
> There should be none, except that we had a bug report whereby GDB would
> create multiple location breakpoint where each location has the same
> line number and file basename, but different directories.
>
> I think you better assume the source location is always the same. You might
> consider if you actually want to display individual locations at all --
> unless the user is in position to do something with address, that information
> is of no use.
>
> - Volodya
Thanks, that makes things a bit simpler. We do need to parse and record
the information for each location, because DDD displays a "glyph" to
indicate the breakpoint location in the machine code display window.
But at least it seems we can make do with only one glyph for the source
code window.
(I suppose I can imagine cases in which the user might want to
enable/disable the individual locations separately, but that seems to be
a rather obscure case).
Peter
>
>