[vox-tech] gdb conditional breaking

[Peter Jay Salzman]

begin Jeff Newmiller <jdnewmil@dcn.davis.ca.us> 
> On Thu, 19 Sep 2002, Peter Jay Salzman wrote:
> 
> > so it appears that here's the rule:
> > 
> > you're allowed to use any function, even library functions, provided that:
> > 
> > 1. the library is linked to your application
> > 2. you actually _use_ the function somewhere in your code.
> > 
> > to be honest, i'm not the least surprised by condition 1, but i'm
> > very surprised by condition 2.
> 
> Why?
 
i don't know why!  if i knew why, i wouldn't be posting the question!

:-)

> For static linking: Modules are the code units that compile into object
> files. Libraries are archives of object files.  During the linking
> process, only those object files with symbols that are needed for your
> program, or to support routines already extracted from the library, are
> actually extracted from the library.  Typically, libraries will be broken
> down into one function per object file to minimize unnecessary loading of
> code.  Thus, linking against a library does not necessarily jglom the
> whole library into your program.
 
ya.  i didn't mention "dynamic" because i thought the static case was
obvious.  we're of one mind here.  :)

> For dynamic linking (shared libraries), only symbol information for those
> functions that you use (directly or indirectly) will be present in your
> compiled program, since there is no need to store unused symbols
> there.  Lacking symbol information in the obvious place, why should gdb go
> looking elsewhere for information that is not likely to be used?
 
ok, i think have the answer, and i don't think you're correct for the
dynamic case.  in particular:

> Lacking symbol information in the obvious place, why should gdb go
> looking elsewhere for information that is not likely to be used?

has a very good answer.  the answer is "because it just does".  :)

an example should illustrate the point:

   p@satan% gdb math
   (gdb) l 1,
   1       #include <math.h>
   2
   3       int main(void)
   4       {
   5               double i = 0.0;
   6               double j = M_PI;
   7               double k = -1;
   8
   9               double l = cos(i);
   10              double m = y0(i);
   11
   12              return 0;
   13      }
   
   (gdb) break 1 if cos(0) <= 1
   Breakpoint 1 at 0x8048450: file math.c, line 1.
   
   (gdb) break 1 if tan(0) <= 1
   No symbol "tan" in current context.
   
   (gdb) break 1
   Note: breakpoint 1 also set at pc 0x8048450.
   Breakpoint 2 at 0x8048450: file math.c, line 1.
   
   (gdb) run
   Starting program: /home/p/writing/ddd/src/math 
   
   Breakpoint 2, main () at math.c:4
   4       {
   
   (gdb) break 1 if tan(0) <= 1
   Note: breakpoints 1 and 2 also set at pc 0x8048450.
   Breakpoint 3 at 0x8048450: file math.c, line 1.


before my code is run, gdb has information on cos() because i use cos()
in the program.  it has no information on tan() because i don't use
tan().

however, after i run the code within gdb, tan() becomes available.  now
the question is, why?

the answer is obvious, at least in a loose sense.  after the program is
run, gdb uses ld.so to bring in code for tan().  since you can't use
ld.so when there's nothing to import code into, tan() isn't available
until _after_ you run the program from within gdb.

so it looks like gdb is capable of using ld.so to link code on the fly
when it needs to.

pete

-- 
Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D