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: Alistair Francis
Subject: Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas
Date: Tue, 23 Jan 2018 16:39:48 -0800

On Thu, Jan 18, 2018 at 8:49 AM, David Hildenbrand <address@hidden> wrote:
> 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?

We support multiple of the same CPU, such as multiple cores. What we
don't support is multiple of different types of CPUs. Something like
ARMs bit.LITTLE or Xilinx's 4xA53s and 2xR5s.

Alistair

>
> 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]