From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecDNp-0005yM-E8 for qemu-devel@nongnu.org; Thu, 18 Jan 2018 11:49:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ecDNm-0004jT-BM for qemu-devel@nongnu.org; Thu, 18 Jan 2018 11:49:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46086) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ecDNm-0004ix-52 for qemu-devel@nongnu.org; Thu, 18 Jan 2018 11:49:42 -0500 References: From: David Hildenbrand Message-ID: Date: Thu, 18 Jan 2018 17:49:38 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alistair Francis , Stefan Hajnoczi Cc: qemu-devel , kvm , Jailhouse On 12.01.2018 00:25, Alistair Francis wrote: > On Wed, Jan 10, 2018 at 4:52 AM, Stefan Hajnoczi wrote: >> On Tue, Jan 9, 2018 at 9:45 PM, Alistair Francis wrote: >>> Can anyone who has done this before chime in. >>> >>> What do you think about getting someone to cleanup and improve the GDB >>> support in QEMU? Would that be the right difficulty of task for a GSoC >>> project? Don't understand that sentence. We already support multiple CPUs (represented and switchable just like threads in GDB), no? An interesting thing to look at could be tracepoint support in GDB. >> >> There is not enough information to give feedback on whether this >> project idea is suitable. What are the specific tasks you'd like the >> student to work on? >> >> In general, I'm sure there are well-defined 12-week project ideas >> around the GDB stub. New features are easy to propose and are usually >> well-defined (e.g. implement these commands that are documented in the >> GDB protocol documentation). Cleaning up code is less clear and it >> would depend on exactly what needs to be done. Interns will not have >> a background in the QEMU codebase and may not be able to make >> judgements about how to structure things, so I would be more careful >> about refactoring/cleanup projects. >> >> Please see my talk about QEMU GSoC for guidelines on project ideas: >> https://www.youtube.com/watch?v=xNVCX7YMUL8&t=19m11s >> http://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf > > That helps a lot, thanks for that. > > So for a more concrete solution, how would adding support for multi > CPU support to the GDB server sound? > > This would allow GDB debugging for the A53 and the R5 on the Xilinx > ZynqMP for example. This is something we have in the Xilinx tree, but > it is in no state to go upstream and really needs to be re-write to be > upstreamable and more generic. > > Alistair > >> >> Hope this helps, >> Stefan -- Thanks, David / dhildenb