Problem running GDB inside a proot

111 views
Skip to first unread message

Sir Civit

unread,
Jan 26, 2014, 2:46:09 PM1/26/14
to proo...@googlegroups.com
I can't seem to get GDB to stop at any breakpoints when running in a proot. I wrote a simple helloworld.c program, only five lines long, then attempted to set a breakpoint on line 4 (printf). Here's what I got:

$ gdb a.out
GNU gdb (GDB) 7.6.2
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-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/main/gdbtest/a.out...done.
(gdb) break main
Breakpoint 1 at 0x40050c: file helloworld.c, line 4.
(gdb) run
Starting program: /home/main/gdbtest/a.out
Hello world!During startup program exited with code 12.


I googled around and found no instances of this problem elsewhere. I don't know for sure if it is proot related, but it is all I can think of. Perhaps it has something to do with the way proot intercepts system calls? i.e. the program shows up in top as ld.so.2 instead of a.out. I'd like to find out if anyone else can fix this or at least reproduce it. Any ideas are appreciated.

Cédric VINCENT

unread,
Feb 3, 2014, 9:01:37 AM2/3/14
to proo...@googlegroups.com
Hello Sir,

Sorry for the delay, I was a bit busy because of FOSDEM :)

> I can't seem to get GDB to stop at any breakpoints when running in a
> proot. I wrote a simple helloworld.c program, only five lines long,
> then attempted to set a breakpoint on line 4 (printf). Here's what I
> got:
[...]
> I googled around and found no instances of this problem elsewhere. I
> don't know for sure if it is proot related, but it is all I can think
> of. Perhaps it has something to do with the way proot intercepts
> system calls? i.e. the program shows up in top as ld.so.2 instead of
> a.out. I'd like to find out if anyone else can fix this or at least
> reproduce it. Any ideas are appreciated.

Both GDB and PRoot relies on ptrace(2) to handle monitored processes.
Although, the Linux kernel allows one "ptracer" per process only, as a
consequence one can't use GDB under PRoot yet. In order to overcome
this limitation, PRoot has to emulate the ptrace syscall internally.
This feature is planned in next release (v3.3, in a couple of weeks).

Cédric.

PS: the programs is named "ld.so.2" because it is the name of the ELF
loader used by PRoot. This will be fixed when PRoot uses its own
ELF loader (not scheduled yet).

Sir Civit

unread,
Feb 8, 2014, 6:22:22 PM2/8/14
to proo...@googlegroups.com
Cédric, thanks for the informative answer! I don't know much about the ptrace system call, but from what you explained it makes perfect sense. I'm happy to hear that a fix is planned, and I'll definitely test it out when the next version is available.

Hello Sir,

Sorry for the  delay, I was a bit busy because of FOSDEM :)

> I can't seem to get GDB to stop at any breakpoints when running in a
> proot. I wrote a simple helloworld.c program, only five lines long,
> then attempted to set a breakpoint on line 4 (printf). Here's what I
> got:

[...]

> I googled around and found no instances of this problem elsewhere. I
> don't know for sure if it is proot related, but it is all I can think
> of. Perhaps it has something to do with the way proot intercepts
> system calls? i.e. the program shows up in top as ld.so.2 instead of
> a.out. I'd like to find out if anyone else can fix this or at least
> reproduce it. Any ideas are appreciated.

Both GDB and PRoot relies on ptrace(2) to handle monitored processes.

Reply all
Reply to author
Forward
0 new messages