This is the mail archive of the gdb@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]

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


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

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