Re: Using gdb to step through gdb in os x leopard
Re: Using gdb to step through gdb in os x leopard
- Subject: Re: Using gdb to step through gdb in os x leopard
- From: Terry Lambert <email@hidden>
- Date: Wed, 8 Jul 2009 11:48:39 -0700
The gdb command itself is a wrapper for /usr/libexec/gdb/*; make sure
you are targetting the right binary.
I also generally recommend that you default start-with-shell off;
there's an historical bug in gdb that may not be fixed in the version
you are using/creating where it ptrace's the child, but ends up with
the Mach port for the shell instead of the Mach port for the child.
This won't cause the symptoms you're claiming here, but it will make
it difficult to intercept signals to the child process, since that's
done via Mach exception ports, and if they get to ptrace, it's too
late, you are going to hit the trampoline in the child whether you
want to or not, since a BSD_AST has been raised on the child of the
shell at that point.
If the following doesn't work for you, you should write up a bug report:
Here's an example; the first gdb is the gdb doing the debugging; the
second gdb is the gdb being debugged; the r command passes a parameter
as the first argument of the second gdb and starts it running under
the second gdb; in this case, /bin/ls; now I am debugging the debugger
debugging /bin/ls:
# gdb /usr/libexec/gdb/gdb-i386-apple-darwin
GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct 2 04:11:19
UTC 2007)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for
shared libraries .......... done
(gdb) r /bin/ls
Starting program: /usr/libexec/gdb/gdb-i386-apple-darwin /bin/ls
Reading symbols for shared libraries ++++++++
+
......................................................................... done
GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct 2 04:17:32
UTC 2007)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for
shared libraries .... done
(gdb) b main
...
I suspect that if you can't do this, you haven't properly integrated
Apple's changes to gdb into the gdb you are attempting to debug (so it
would make sense that you were trying to debug it...).
-- Terry
On Jul 8, 2009, at 3:43 AM, Aron-Zvi wrote:
Thanks for the detailed reply Terry.
I've tried running the entire thing as root by switching with su
before running the command. I've even tried logging in as root.
gdb --args ./gdb fooprogram as root still results in "Unable to find
Mach task port for process-id pid_of_ fooprogram (os/kern) failure
(0x5)" in the debugee gdb when attempting to run fooprogram.
Once again, this happens in macosx_ptrace_him() after task_for_pid() .
How do I get this working?
Thanks in advance,
Aron-Zvi
On Wed, Jul 8, 2009 at 9:55 AM, Terry Lambert <email@hidden>
wrote:
On Jul 7, 2009, at 6:34 PM, Aron-Zvi wrote:
Hey guys,
I've downloaded and built the most recent gdb available at
opensource.apple.com - gdb-966.
I'm running OS X Leopard 10.5.7.
I'm stepping through gdb with gdb like so: gdb --args ./gdb fooprogram
gdb fails in macosx_ptrace_him() following the task_for_pid() call.
task_for_pid() returns 5 which i believe is KERN_FAILURE. The
message displayed in the debugger is "Unable to find Mach task port
for process-id 8455".
When I run just ./gdb fooprogram - everything works fine.
gdb's gid is set to procmod. Furthermore, I've even tried running
gdb as root with identical results.
How can I use gdb to step through gdb debugging another process?
As a setgid program, you will be unable to debug it unless you run
the gdb you are using to debug it as root.
This is an intentional security feature in task_for_pid() and in
ptrace() to preclude you using the debugger to debug a program with
escalated privilege and thus access code, data, or interfaces which
you would otherwise not be privileged to access or execute as a
privileged user or group. It doesn't matter that the group is the
same as gdb itself is running as, what matters is that the
credential for that user has been adulterated away from the identity
given to the system by DirectoryServices or whatever authentication
database you are using to establish the credential in the first
place. Credentials are established by escalating privilege, setting
up the credential, and dropping privilege. If you run a program
that re-escalates privilege, unless it does the little dance to
establish its rights to establish a new kernel credential
authoritatively, privilege is revoked. In your case, your gdb is
only sgid, so it's incapable of obtaining root privilege in order to
become an authoritative source of credential information for the
kernel. This is also generally why we ask people to rely on login
as a gatekeeper, rather than writing their own credential
establishing code.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden