From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9089 invoked by alias); 21 Sep 2009 19:19:54 -0000 Received: (qmail 9077 invoked by uid 22791); 21 Sep 2009 19:19:53 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,J_CHICKENPOX_45,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Sep 2009 19:19:47 +0000 Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 24EB278494A4; Mon, 21 Sep 2009 12:19:46 -0700 (PDT) Received: from gdbrulez.apple.com (gdbrulez.apple.com [17.224.14.42]) by relay16.apple.com (Apple SCV relay) with SMTP id D4.81.06198.2D1D7BA4; Mon, 21 Sep 2009 12:19:46 -0700 (PDT) Subject: Re: [ANNOUNCEMENT] GDB 7.0 release process created Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Jim Ingham In-Reply-To: <20090921134617.GA30967@bromo.med.uc.edu> Date: Mon, 21 Sep 2009 19:19:00 -0000 Cc: gdb@sourceware.org Content-Transfer-Encoding: 7bit Message-Id: <187A0C0A-28B7-4A51-BE99-47C0F650C1F8@apple.com> References: <20090920143231.GQ7961@adacore.com> <8ac60eac0909200802m45f2675epa6e56001af4b491@mail.gmail.com> <20090920152741.GR7961@adacore.com> <8ac60eac0909200914g39a2d471j601aebd995da1d02@mail.gmail.com> <20090920171154.GT7961@adacore.com> <20090920173607.GA18628@bromo.med.uc.edu> <8ac60eac0909201137h3b357f95hc9471ed186575c06@mail.gmail.com> <20090921043410.GA25454@adacore.com> <20090921125654.GA30075@bromo.med.uc.edu> <3D48AF75-6E1F-401C-8411-8388B7D893B9@elis.ugent.be> <20090921134617.GA30967@bromo.med.uc.edu> To: Jack Howarth X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00277.txt.bz2 Sorry, I don't watch the llvm lists. My understanding was that the OS Security folks were not planning to turn off procmod in SnowLeopard. A quick test shows the Apple gdb built setgid procmod but not codesigned was able to debug. Maybe now you do need the plist (see point 1 below...), though? At some point, however, the procmod access will go away - or so I was told... Here is the "official" way task port access is granted on SnowLeopard (this is what will continue to be supported in the future): 1) In order to have task port access, the process has to request it using a plist baked into the binary. If you look at Apple's gdb sources in the src/gdb directory, the plist is in the Info.plist file, and it gets added by adding a -sectcreate option to the link line in the Makefile. 2) Then the binary also has to be codesigned by some authority that is recognized by the user. You can easily make an appropriate codesigning authority with the Certificate Assistant which is part of the KeyChain Access tool, or if the FSF already has one that you can use, that's even better. I make an unvalidated one by hand for my own development purposes, and there's a target in the gdb Makefile: "codesign-gdb" that does the codesigning on the gdb binary if you need to see how that is done. The annoying bit here is that you have to ship and install the certificate along with the binary, since the user has to say they trust it. 3) There's another trick to this, however, which is that even if you fill these requirements, the user will be asked to authenticate to use the debugger once per login session. This is done by the taskgated daemon that "task_for_pid" calls down to, and it will put up a dialog box if gdb is running in a session that can connect to the Window Server. That's okay for gdb running in a terminal session on your local machine, but doesn't work if you are ssh'ed into the machine. Fortunately there are API's that you can use to request this permission so you can query for the password in the terminal if you want. There's a function "macosx_get_task_for_pid_rights" in the SnowLeopard sources for gdb (in macosx-nat-inferior.c) that does just that. The gdb that Apple ships gets special treatment because it is codesigned by the Apple codesigning authority. I forget all the details, but I don't think that this treatment is available to non- Apple codesigned apps. Again, I am pretty sure steps 2 & 3 are NOT necessary for SnowLeopard. Jim On Sep 21, 2009, at 6:46 AM, Jack Howarth wrote: > On Mon, Sep 21, 2009 at 03:35:55PM +0200, Jonas Maebe wrote: >> >> Apple's gdb developers are usually quite responsive on Apple's xcode- >> users list: http://lists.apple.com/mailman/listinfo/xcode-users >> >> >> Jonas > > Jonas, > I'll wait and see what response I get from my post on llvm-dev first > (as all the heavy lifting is on llvm/clang at Apple now). Actually, I > just found out on llvm-dev last Friday that libgcc in Snow Leopard is > actually subsumed into libSystem now (and the FSF libgcc is never > actually used). Never heard that anywhere else before. Makes life > interesting when a compiler is creating exception handling for a > completely > different unwinder than the one actually used at runtime. > Jack