3

Is there a simple way of setting the affinity of the application I'm debugging without locking gdb to the same core? The reason why I'm asking is that the application is running with real time priority and it needs to run on a single core. At the moment I use this command line

taskset -c 3 gdbserver :1234 ./app.out

but the application stops responding and freezes the gdb server, making debugging impossible. I suspect that the real time priority of the application prevents gdb from executing. If I start the application and then start gdb without affinity setting, then I can attach and debug the application without gdb freezing.

Is there a simple way to start gdb and the application with different affinities? Or preferably: Is there a gdb command to set affinity of the child process?

Marcus Ahlberg
  • 1,329
  • 2
  • 11
  • 24

2 Answers2

1

I found a solution: Use the --wrapper argument.

http://sourceware.org/gdb/onlinedocs/gdb/Server.html

gdbserver --wrapper taskset -c 3 -- :1234 ./app.out
Marcus Ahlberg
  • 1,329
  • 2
  • 11
  • 24
1

I had a similar problem and found a solution for myself, drawing in fact from your question for inspiration. As you suspect, it is possible that your gdbserver freezes when running on the same core because one of your application threads is using all the core's cycles and gdbserver is not allowed to run because its priority is too low.

For my particular needs, I am using gdb for an application employing realtime scheduling running on the local machine, and I don't mind if gdb runs on the same core, but I want to be able to debug my program with all the priorities of the application threads respected. For me, what made things work was expanding the gdb command to this more complex construction:

taskset -c 3 chrt 99 gdb

The chrt command added to your taskset command switches to the SCHED_RR policy and runs gdb at the specified priority. My threads being debugged run themselves with lesser priority, and so I assume they only run when gdb is not running.

I was having a problem before. I think, when I requested gdb to resume execution after gdb had suspended execution at a breakpoint or so, that one thread would start running before a higher-priority thread was resumed and thus it was not always the thread that I expected to be running that was in fact running. For me, the above command seems to fix everything -- I assume because the application threads can only run when gdb has finished everything it needs to do in order to resume the program. So, I guess the command line that would be applicable in your case if you wanted to try this out would be:

taskset -c 3 chrt 99 gdbserver :1234 ./app.out

Note: so this would lock gdbserver to a certain core, but likely your real time threads would (or probably could) be running at a lesser priority and so gdbserver would not freeze on you.

Craig Scratchley
  • 11
  • 3
  • This is your answer that finally worked also for me [Linux not respecting SCHED_FIFO priority ? ( normal or GDB execution )](https://stackoverflow.com/q/64061391/3972710) – NGI Sep 30 '20 at 09:08