Caveat: This isn't so much a complete solution as some workarounds and suggestions [that are too big to fit into a comment].
There's basically two issues:
- Does gdb's
r
command [under macOS] allow input redirection?
- Can
gdb
be run under sudo
?
So, let's start by eliminating sudo
. Does the following work:
gdb ./executable
r < input.txt
If not, either the run
command's input redirection does not work or there is a bug in the executable.
Side note: For many years, I did not know that run
could take I/O redirection [silly me :-)].
What I usually do/did is modify the program to allow input either from stdin
or from an argument [just like cat
]. Then, I'd do:
gdb ./executable
set args input.txt
run
The other issue is whether gdb
can be run under sudo
.
In the past, I've tried to debug a setuid
executable as an ordinary user [if possible]. This eliminates the complexity of trying to run gdb
and the executable as root
. Sometimes this involves creating a test directory that mirrors/mimics the necessary file hierarchy [but the files are owned by the non-root user] and using (e.g.) chroot
or equivalent
Much of the debug can be done this way without root privileges. For the parts that do require root, I often resort to printf
debug messages--YMMV.
I'm not familiar with macOS, so I don't know how [the aformentioned] SIP
will respond to the following ...
Another trick I've used is to make the executable [and a copy of gdb
] into setuid
programs:
cp /usr/bin/gdb /home/me/mygdb
sudo chown root /home/me/mygdb
sudo chmod 6741 /home/me/mygdb
sudo chown root /home/me/myprogram
sudo chmod 6741 /home/me/myprogram
Then, I run the modified programs. This can bypass some of the issues with using sudo
directly on the target programs.
Of course, I try to make sure that there is no access to the containing directory by others. And, I remove the files when done testing.