From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71681 invoked by alias); 29 Feb 2016 09:42:03 -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 71667 invoked by uid 89); 29 Feb 2016 09:42:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=luxury, fashion, them!, reuse X-HELO: mail-wm0-f47.google.com Received: from mail-wm0-f47.google.com (HELO mail-wm0-f47.google.com) (74.125.82.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 29 Feb 2016 09:42:00 +0000 Received: by mail-wm0-f47.google.com with SMTP id p65so60120687wmp.1 for ; Mon, 29 Feb 2016 01:42:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=PMmUGd1EjU1J0ZJiGe+yR101dh8qZZUIkc6uyBitIw8=; b=Mq71u0Bj6ntINlhyR8Tm8QVmDgLe14yBByC5IetkGdncwrkFHv4JOE0kdOpYFXr5/l ZmtU8dLjmNu06H0fJu3yCfqjGbwfpZaPF+7JfWjRttD1r2+uokfp+gkhw3wJkP+nMUrQ nbMr/jpGCkaeooPzIdx6BzdZ6gvrmokN7ieGeycdd+5g+fHepEMESLEg/vKVzouRXilW ENZecqALqLeZpcPih0k6haayA8l388im3ZX6Adwr1hH//TYur1yja3q7ePYyqdtGx1hs poP+HrD4bKM5K7H/+E0ak1KtlJmAz9r5RRwr2ZD0OeMM9/A7ygakMRwfc4SFB1XyPBDs lafw== X-Gm-Message-State: AD7BkJLlOdBFxxCimEGMFOt17L7rd3iZJkEsxIQsdZRF52xA+F1OSMc1dxptAANE9HUGYg74 X-Received: by 10.28.63.85 with SMTP id m82mr11424208wma.55.1456738917460; Mon, 29 Feb 2016 01:41:57 -0800 (PST) Received: from [192.168.0.10] (cpc87017-aztw30-2-0-cust65.18-1.cable.virginm.net. [92.232.232.66]) by smtp.gmail.com with ESMTPSA id c128sm6490878wma.11.2016.02.29.01.41.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Feb 2016 01:41:56 -0800 (PST) From: Kieran Bingham Subject: Re: [RFC PATCH 0/4] GDB Linux Kernel Thread Awareness To: Jeff Mahoney , gdb-patches@sourceware.org, yao.qi@linaro.org References: <1456427706-30077-1-git-send-email-kieran.bingham@linaro.org> <56CF5E2A.9030905@suse.com> Cc: arnez@linux.vnet.ibm.com, peter.griffin@linaro.org, lee.jones@linaro.org, russell.wayman@linaro.org, kernel@stlinux.com Message-ID: <56D41263.5070504@linaro.org> Date: Mon, 29 Feb 2016 09:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56CF5E2A.9030905@suse.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00885.txt.bz2 On 25/02/16 20:03, Jeff Mahoney wrote: > 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 ways of >> upstreaming this functionality. >> >> This functionality implements the 'possible improvements' Related to Execution >> 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 tasks. >> Switching to a specific task, then functions as expected with 'thread NN', and >> 'bt' to produce a back trace of that thread. >> >> 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 awareness. >> >> Now that I have separated out the LKD code from the ST's internal STMC code, >> it could also be possible to publish the larger project if it is of relevance, >> though that will be heavier reading than this reduced patch. >> >> 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. >> >> 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 layer >> 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. Yes, I believe it is due to the difference in target. You have the (wonderful) luxury of parsing the task list once and then leaving it so :) I have been able to provide an ARM register set up function, which then allows me to update the thread list at the first instance, and examine the backtraces of each thread, in the same fashion as yours - but I need to be able to make it more dynamic. I will need to be able to update the list after a target continues, and hence have been trying to use the to_update_thread_list hook. If a python implementation tries to check the GDB thread list from within this hook (perhaps not an unreasonable thing to do given the request) GDB tries to update the thread-list and ... well I'm sure you see where that goes. It seems similar with the register reads too. I have added in a static variable to make sure the functions aren't re-enterered, but this is seeming to upset GDB internally, if the Python then causes GDB to try to request the registers, and they aren't yet available - we can end up with GDB not having access to a thread PC and failing to unwind. It feels a bit fragile when it can upset GDB so much, and so a viable python interface would need to be able to protect against actions that can be done in external python scripts. If anyone from @gdb has ideas on how this protection could be done - I'd love to hear them! (You guys know the internals much better than me of course) Hopefully not insurmountable problems of course - but ones that will take time, and thought - which for this project has to be weighed up against the existing solution (this patch set) -- Regards Kieran > > -Jeff >