qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas


From: David Hildenbrand
Subject: Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas
Date: Thu, 18 Jan 2018 17:49:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 12.01.2018 00:25, Alistair Francis wrote:
> On Wed, Jan 10, 2018 at 4:52 AM, Stefan Hajnoczi <address@hidden> wrote:
>> On Tue, Jan 9, 2018 at 9:45 PM, Alistair Francis <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]