l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
January 6: Social gathering
Next Installfest:
TBD
Latest News:
Nov. 18: Club officer elections
Page last updated:
2002 Sep 20 11:15

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] gdb conditional breaking
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] gdb conditional breaking



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
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.