1

Just like it says above. The program needs to be invoked in sequence with others, by a script and I'd like to have it run automatically so that it is as true to the actual running conditions as possible.

Edit

I wasn't able to find an answer to this, but just in case someone comes looking here's how I worked around it, since I had access to gdb and screen on the target.

screen -d -m gdb -x debugstart

where debugstart is a simple script containing:

file program
r

this will launch a screen session and start gdb in it which starts running your program and then detatch from that screen session so you can just screen -r when you need to look at the debugger.

Julio Guerra
  • 5,523
  • 9
  • 51
  • 75
L.McCauslin
  • 346
  • 4
  • 14

1 Answers1

1

You don't explain why you want GDB to trace your program, and I guess it is to catch errors at run time (e.g., signals of fatal errors), which is a good practice in case of hardly reproductible errors.

So one way is to run gdbserver using the option --multi. You'll then be able to remotely run your program and then to stop its execution pressing ctrlc (or command interrupt).

Running gdbserver

$ gdbserver --multi <server address>

GDB script:

target extended-remote <server address>
remote put <your program>
set remote exec-file <your program>
# you could pre-set breakpoints, or whatever
run
# ctrl-c to interrupt the execution of the started process

Otherwise, you could simply run your program and then remotely attach to it with gdbserver --attach when required.

Julio Guerra
  • 5,523
  • 9
  • 51
  • 75
  • As you guessed I was trying to catch a fatal error. However, that error only ever seemed to occur if it was invoked during system startup, so there was no way to run gdbserver --attach before it would have crashed. I'm not sure that gdbserver was the right approach in the first place anyway. – L.McCauslin Jan 31 '17 at 18:27
  • the correct command is `remote put ` – Necktwi Sep 19 '22 at 03:11