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:
December 2: Social gathering
Next Installfest:
TBD
Latest News:
Nov. 18: Club officer elections
Page last updated:
2002 Sep 11 16:07

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 question: rbreak
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] gdb question: rbreak



Pete,

  If this doesn't help let me know what you are after...

>    (gdb) rbreak m.*

  You may have meant 'rbreak ^m' instead...  'm' and 'm.*' mean the 
same thing from a RE perspective... and that '.*' does not force m 
to match the beginning of a string.  the argument to rbreak is not 
wrapped in a '^', '$' pair, it is allowed to match any part of
the function name string.

On Tue, Sep 10, 2002 at 08:00:39PM -0700, Peter Jay Salzman wrote:
>    Non-debugging symbols:
>    0x08048298  _init
>    0x080482d0  __register_frame_info
>    0x080482e0  __deregister_frame_info
>    0x080482f0  __libc_start_main
>    0x08048300  printf
>    0x08048310  _start
>    0x08048334  Letext
>    0x08048334  call_gmon_start
>    0x08048360  __do_global_dtors_aux
>    0x080483b0  fini_dummy
>    0x080483b8  frame_dummy
>    0x080483dc  init_dummy
>    0x08048412  Letext
>    0x08048420  __do_global_ctors_aux
>    0x08048444  init_dummy
>    0x0804844c  _fini
[...]
> now if i look at crtbegin.o:
[...]
> even here, with no debugging symbols, rbreak catches glibc stuff:

  Okay clear, those symbols you are calling 'glibc stuff' do 
not belong to glibc.  They belong to gcc are are from crt*.o, if you 
run gcc with -v you will see a number of files being linked in the 
final link stage.  Most of these files are part of the c compiler.
Some are part of libc-dev and are practically required to produce a
executable.

  I don't know how this magic works but I vaguely understand that these
crt*.o files are part of the interface between the kernel, libc, and a 
c program's main function (to handle setup of argc, argv, stdin, stdout,
etc, and later return value).  


  Just for kicks if you wanted to get symbols from libc in the rbreak
you need to have that library loaded first, the method I would use is
to:
====
b main
run
rbreak f
# hit return a few times
run
====

  this will set about 485 break points, the reason for the first run is
to get the symbols from that library loaded, the reason for the second
run is to have them applied because 10 or so these functions are called
before main.

> hrm, i'm not sure how init_dummy+6 matches f.*.

  both p and init_dummy were not matched here, on this machine I only 
got two fini and frame functions, but I don't use gdb to a attach .o 
normally, so I'm supprised things worked as well as that.

I use nm to track down which symbols are present in a object file.
  nm --defined-only -o /usr/lib/gcc-lib/i386-linux/2.95.4/crtbegin.o


> > > having gdb mention anything about libc functions is a big nuissance.
> > > what do you suggest i do to make rbreak ignore libc function?
[...]
> i'm at a loss here.  any advice?  :(

  so to answer what you asked, "ignore libc functions", then use:
===
nosharedlibrary
rbreak ^f
===

  to explain how that works, since most people use libc is a shared 
library and the 'nosharedlibrary' statement will cause gdb to forget 
all symbols loaded from shared libraries so stuff from libc will 
be forgotten, so you will get no symbols from there bothering you.

  so if the question is "ignore functions from crt*.o", uhm, a few
options methods make your REs more specific, or use a .gdbinit
file to set your breakpoints...

.gdbinit:
===
b f
b foo
b f1
display x
run a b d
===

  if you are debugging a complex piece of code you can over time
grow a .gdbinit file that does most of the setting things up for you 
automatically (with watch points and such) so that the debugger
first stops when a problem has been detected.
_______________________________________________
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:
Sunset Systems
Who graciously hosts our website & mailing lists!