From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89788 invoked by alias); 25 Feb 2016 20:04:11 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 89769 invoked by uid 89); 25 Feb 2016 20:04:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=continued, meet, our X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Thu, 25 Feb 2016 20:04:09 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 25967AB9D; Thu, 25 Feb 2016 20:04:05 +0000 (UTC) Subject: Re: [RFC PATCH 0/4] GDB Linux Kernel Thread Awareness To: Kieran Bingham , gdb-patches@sourceware.org References: <1456427706-30077-1-git-send-email-kieran.bingham@linaro.org> Cc: arnez@linux.vnet.ibm.com, peter.griffin@linaro.org, lee.jones@linaro.org, yao.qi@linaro.org, russell.wayman@linaro.org, kernel@stlinux.com From: Jeff Mahoney Message-ID: <56CF5E2A.9030905@suse.com> Date: Thu, 25 Feb 2016 20:04:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1456427706-30077-1-git-send-email-kieran.bingham@linaro.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="g3IqJ6RlRDgE3O38RI8HkBlMtsWWR2NV0" X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00832.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --g3IqJ6RlRDgE3O38RI8HkBlMtsWWR2NV0 Content-Type: multipart/mixed; boundary="1twPwuRmAFwMvhN1cODEQQRpcxxBCcXeH" From: Jeff Mahoney To: Kieran Bingham , gdb-patches@sourceware.org Cc: arnez@linux.vnet.ibm.com, peter.griffin@linaro.org, lee.jones@linaro.org, yao.qi@linaro.org, russell.wayman@linaro.org, kernel@stlinux.com Message-ID: <56CF5E2A.9030905@suse.com> Subject: Re: [RFC PATCH 0/4] GDB Linux Kernel Thread Awareness References: <1456427706-30077-1-git-send-email-kieran.bingham@linaro.org> In-Reply-To: <1456427706-30077-1-git-send-email-kieran.bingham@linaro.org> --1twPwuRmAFwMvhN1cODEQQRpcxxBCcXeH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-length: 1909 On 2/25/16 2:15 PM, Kieran Bingham wrote: > I've wanted to get some actual code out for a while and as such I have > tried to strip down the implementation of LKD to the bare essentials for > implementing thread awareness. I hope to get some feedback on the best wa= ys of > upstreaming this functionality. >=20 > This functionality implements the 'possible improvements' Related to Exec= ution > Contexts as mentioned in Andreas' slides on slide 18 [1] and allows a user > to perform 'info threads' and see the currently running and sleeping task= s. > Switching to a specific task, then functions as expected with 'thread NN'= , and > 'bt' to produce a back trace of that thread. >=20 > Indeed this patch set hopes to satisfy Andreas' request in [2] to submit a > small patchset of the initial features. In this case, the thread awarenes= s. >=20 > Now that I have separated out the LKD code from the ST's internal STMC co= de, > it could also be possible to publish the larger project if it is of relev= ance, > though that will be heavier reading than this reduced patch. >=20 > This implementation is in C and heavily derived from the implementation > created by ST, as the aim of the upstreaming project is to reuse as much > of the ST implementation as is reasonable. >=20 > The python-ic version of this that I've been working on (gdb.Target) hits= a > few problems, in guarding against infinite recursion as many of the python > API's end up calling back into the target layer, and exceptions in that l= ayer > tend to make GDB crash in very un-user-friendly ways. FWIW, I've continued to use your Python implementation and have extended it to meet our needs. I haven't encountered the recursion you describe, but it may be that I haven't pushed it hard enough yet. I think you're probably more focused on active targets while we're mostly working on dumps. -Jeff --=20 Jeff Mahoney SUSE Labs --1twPwuRmAFwMvhN1cODEQQRpcxxBCcXeH-- --g3IqJ6RlRDgE3O38RI8HkBlMtsWWR2NV0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 881 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJWz14wAAoJEB57S2MheeWy1KIP+wUe9aD2bZxe6EYUGQbKWTsH qlRvixKHVkXxAWs14k7F02TQP3N76ge6fHkSmVjZ2ntZhBeKgyQCUmIzP7VzEYfF 7GxzHH/gtZuCfi/VlS6o/wQRMTp5ILehtPVw1paUIsIVvuqU/BBbQUO7NPt4BJzY V4/IDXolNgKfe7l56hIIByJmpbBCrn4ErYWyc7X2/crHdG8mQ0alof2g6LP/FJeq eRGioV4AEXJd1uDKZ9k5xXWd6fhRl4j68JZmm7wvDp74ecvF2zBrOzi5+ohT1tt/ curqRP9aFncK4md/b/chN7/U1VR3vSo/LR9YH20dAwREFqaqdrs/D62uGkOWN26s 5gj0ATf4hCMZq5vfwQTyscW2Ts/Q/hwj7qc1sQuhjl4a1I7rXp2PMm22slVc7yil k8XrOxZ11YDuI92qugxIpTCIRLv9zOQdKJQBxLjQAiixgeg2hC/eyF4yGPsxhJeD c5E5quu5RxZlIxVosqDPhd9BcovdDiqcVpI/rujDg77RZpKh28fo0bKhjzk6E06k v69+xIk5RnIcNMvP/7gmGwqJ1NUumi2gG+YM4a2vpVYMLCtx3Tg4L6ZdnqLKvuDX rm2I8YQFqiQdUlo8JwmTl2O1I0B51XY4B3W0/hPc9Auoy3rbHiinVsLbpO0SqPKH tNR3ze74AyU6Jbju2jae =mJKJ -----END PGP SIGNATURE----- --g3IqJ6RlRDgE3O38RI8HkBlMtsWWR2NV0--