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