Breaks in include files (was :RE: breakpoint setting weirdness in C++)

Fabrice Gautier Fabrice_Gautier@sdesigns.com
Thu Nov 2 21:06:00 GMT 2000


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

Well this is interresting... It seems the code is really duplicated in each
object file but is then only one survive thanks to the "linkonce" attribute
(even if they are differents which can happen with ugly preprocessor
directives) 

This means you can do write some code and the result will depend of the
order of the source files on the command line...

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


Yes, but now consider the following "C" case:

fun.h:
static void fun(void)
{
 int i=1;
}

fun1.c:
#include "fun.h"
void fun1(void)
{
 fun();
}

void main(void)
{
 fun1(); 
 fun2();
}

fun2.c:
#include "fun.h"
void fun2(void)
{
 fun();
}

In this case I think the static function are really duplicated. And it is
possible to set a breakpoint on fun.h but it will only be set on one of the
"fun" function. The fun symbol is present twice in the executable but I
guess either the debug information has not been duplicated, either the
symbol lookup doesn't bother with potential duplicates.

By the way if i type "break fun" instead of"break fun.h:3", the breakpoint
is wrongly set and never reached...

Regards,

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 


More information about the Gdb mailing list