I don't think the permission denied is necessarily talking about the traditional permissions bits (rwx..), rather I'd be suspicious of something like SELinux or AppArmor which might be denying your process access.
I do not have access to a ArchLinux system but there is something similar under Fedora that is discussed here in this Fedora Wiki topic: Features/SELinuxDenyPtrace.
Here they're blocking access to ptrace through SELinux, so you might want to try disabling either SELinux or AppArmor is ArchLinux happens to be using either.
What your attempting worked for me
I tried you code on my Fedora 19 system and other than needing to install some addtional debuginfo RPMs it worked as you'd expect it to.
Example
Compiled your code.
$ gcc -g test.c
Ran the resulting binary in gdb
.
$ gdb a.out
GNU gdb (GDB) Fedora 7.6.1-46.fc19
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/saml/tst/106912/a.out...done.
(gdb) break main
Breakpoint 1 at 0x40053f: file test.c, line 4.
(gdb) run
Starting program: /home/saml/tst/106912/a.out
Breakpoint 1, main (argc=1, argv=0x7fffffffd698) at test.c:4
4 printf("1\n");
Missing separate debuginfos, use: debuginfo-install glibc-2.17-20.fc19.x86_64
(gdb) quit
A debugging session is active.
Inferior 1 [process 13341] will be killed.
Quit anyway? (y or n) y
The debugger complained that I was missing the debuginfos for glibc so I installed them.
$ sudo debuginfo-install glibc-2.17-20.fc19.x86_64
Now when I re-run gdb
.
$ gdb a.out
GNU gdb (GDB) Fedora 7.6.1-46.fc19
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/saml/tst/106912/a.out...done.
(gdb) break main
Breakpoint 1 at 0x40053f: file test.c, line 4.
(gdb) run
Starting program: /home/saml/tst/106912/a.out
Breakpoint 1, main (argc=1, argv=0x7fffffffd698) at test.c:4
4 printf("1\n");
(gdb)
The problem is probably that the gdb server output is being blocked because no one reads it, so the gdb client is also blocked. You can get expect
to read and ignore the rest of the output from gdb with
expect_background eof exit
which makes the last spawned command continue with its output until end-of-file is read.
Best Answer
You can pass commands to gdb on the command line with option
-ex
. You need to repeat this for each command. This can be useful when your program needs to read stdin so you don't want to redirect it. Eg, forod -c
So in particular for your question, you can use: