0

I have an executable that was built from a lot of *.c and *.h files. When I use the following GDB command to add breakpoints:

rbreak .

it does the job, but it takes a VERY long time to finish, because it wants to put breakpoints in libc, openssl and other functions from 3rd party libs that I really don't care about.

How can I put these breakpoints quickly in my functions?

Here are some ideas how that could be achieved, but I am not sure if GDB supports any of them

  1. instruct GDB not to put breakpoints in 3rd party libs; or
  2. by silencing GDB's confirmation for each added breakpoint (it gets printed to console and may slow things too).
  3. somehow match regex on files when invoking the rbreak command?

Note that my functions don't have a naming pattern that could be matched with a regular expression.

user389238
  • 1,656
  • 3
  • 19
  • 40

1 Answers1

0

instruct GDB to put breakpoints in all of my functions

In general, this request suggests that you may have an XY problem. I've been using GDB for over 20 years for all kinds of programs, and I am hard pressed to think of a reason to want to do what you want to do.

That said, apparently newer versions of GDB support rbreak foo.cc:.* syntax, as this answer indicates. See also this answer for an alternate recipe.

Update:

What I am trying to do by putting all these breakpoints is to use gdb as tracer

Ok, you do have an XY problem. Instead of using GDB as a tracer, compile in an actual tracer -- it will be a 1000 times faster and will just work(TM). Instructions here and here.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Is there a gdb version where instead of foo.cc I could use regex for filepaths? What I am trying to do by putting all these breakpoints is to use gdb as tracer (by using gdb commands that would print stacktrace and resume execution). – user389238 Nov 28 '18 at 05:04
  • While I would prefer to avoid recompilation, have to admit that those tracing approaches may look promising. However, do they allow to print function arguments like trace-cmd is able to do when tracing kernel or just the function names? I believe to be correctly able to do that I need debug symbols, no? – user389238 Nov 28 '18 at 07:52
  • @HansSolo In order to trace and print all arguments, you would have to use GDB (or something like it). However, you never stated *why* you want such a trace. What is the *actual* problem you are trying to solve? – Employed Russian Nov 28 '18 at 15:25
  • I am troubleshooting a software switch that does not forward occasional packets. Yes, I actually need a user-space process tracer and thought to "implement" it in GDB. I would prefer that this tracer could log function arguments (to allow gather more helpful info to pinpoint issue quicker) and would allow to trace process without rebuilding executable (otherwise, I would need to eliminate all discrepancies between my dev station and buildserver, like, static libs, .config.h etc) and would not be disrupting traffic for too long (immediately resume execution once breakpoint is hit). – user389238 Nov 28 '18 at 22:48