This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Breaks in include files (was :RE: breakpoint setting weirdness in C++)
- To: 'Daniel Berlin' <dberlin at redhat dot com>, Fabrice Gautier <Fabrice_Gautier at sdesigns dot com>
- Subject: Breaks in include files (was :RE: breakpoint setting weirdness in C++)
- From: Fabrice Gautier <Fabrice_Gautier at sdesigns dot com>
- Date: Thu, 2 Nov 2000 21:05:20 -0800
- Cc: gdb at sources dot redhat dot com
>
> 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