Re: breakpoint setting weirdness in C++

[Daniel Berlin <dberlin at redhat dot com>]

Fabrice Gautier <Fabrice_Gautier@sdesigns.com> writes:

> >
> > Two things strike me as weird. The first is that I cannot set a
> > breakpoint in a *.h or *.i file unless I first set a breakpoint in a
> > *.cpp file beforehand. The second is that when I set the breakpoint in
> > the log.cpp file it did not print out the absolution pathname as it
> > did for the log.h and log.i files. Any clues?
> 
> Well, I don't have any ideas of the logic inside gdb to set source
> breakpoints but i've some feelings:
> 
> First it seems awkward to set brekapoint in includes file. Do they really
> contains codes? Usually not but it is possible.

No, they actually contain code quite a lot of the time.
Remember, we have classes and templates in C++.

If i have 
test1.h:

class dan
{
       int foo()
        {
                return 5;
        }
};


This code will *not* be duplicated in each source file that includes
it, unless dan is instantiated, and foo is called the in source file.
Then, and only then, will it be emitted.
However, the code certainly lives in the .h file.
Same with most templates.
They exist in the .h's.
Most of the STL is like this



        
>  But usually such code is
> either inlined or it will be "duplicated" in each source file where it is
> included. So this doesn't seems very logical. Yet I guess in C++ this
> happens quite often.
No, it doesn't, only templates instantiated in multiple source files
have duplicate code problems, and we solve that bloat by linkonce
sections to make sure only one copy of the function gets into the
executable.

> 
> Anyway, the compiler won't compile the .i or .h files but will for the .cpp
> files. And so i guess that when including debugging information gcc have to
> include some kind of info in each ".o"  file that include an .h. So when you
> want to access some info in the ".h" file you need to know from what file it
> has been included. This means you have to precise the ".c" file
> before.

You don't have to know what file the file is included from, only that
the function lives in that file.


> So maybe this is what is done by gdb. When you set the breakpoint to the
> source file then it have some contextual informations.
> 
> This is pure speculation of my part but that seems plausible.
> 
What's likely happening is that gdb isn't properly doing the lookup to
find the symbol he's looking for in the .h file.
If this is a CVS tree from the past week or so, this is my fault, and
it'll be fixed tomorrow.
Otherwise, something is wrong with determining when we need to read in
symtabs.