From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LNuJb-00019L-OS for qemu-devel@nongnu.org; Fri, 16 Jan 2009 14:25:11 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LNuJa-00017o-Sc for qemu-devel@nongnu.org; Fri, 16 Jan 2009 14:25:11 -0500 Received: from [199.232.76.173] (port=57426 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LNuJa-00017d-Ms for qemu-devel@nongnu.org; Fri, 16 Jan 2009 14:25:10 -0500 Received: from fmmailgate01.web.de ([217.72.192.221]:55963) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LNuJa-0001uh-1h for qemu-devel@nongnu.org; Fri, 16 Jan 2009 14:25:10 -0500 Message-ID: <4970DF0C.4090505@web.de> Date: Fri, 16 Jan 2009 20:25:00 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RESEND][PATCH] gdbstub: Add vCont support References: <496DFA33.2020606@siemens.com> <200901160015.44729.paul@codesourcery.com> <49703FAD.1060107@web.de> <200901161705.18981.paul@codesourcery.com> In-Reply-To: <200901161705.18981.paul@codesourcery.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6BAD41568F1F6A0CE7FF08D3" Sender: jan.kiszka@web.de Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6BAD41568F1F6A0CE7FF08D3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul Brook wrote: > On Friday 16 January 2009, Jan Kiszka wrote: >> Paul Brook wrote: >>>> a) Modeling cpus as processes buys us nothing compared to threads g= iven >>>> the fact that we cannot provide a stable memory mapping to the g= db >>>> frontend anyway. (*) >>> I disagree. The process model fits perfectly. The whole point is that= >>> each CPU has its own virtual address space. Separate address spaces i= s >>> the fundamental difference between a process and a thread. >>> >>> If you have a multicore system where several cores share a MMU[1] the= n >>> modelling these as threads probably make sense. >>> >>> Don't confuse this with OS awareness in GDB (i.e. implementing a >>> userspace debug environment via a bare metal kernel level debug >>> interface). That's a completely separate issue. >> You snipped away my argument under (*): >>> (*) Process abstraction is, if used at all, guest business. At best w= e >>> could try to invent (likely OS-specific) heuristics to identify >>> identical mappings and call them processes. I don't see a reasonable >>> benefit compared to the expected effort and unreliability. >=20 > You're doing exactly what I said not do do. You are confusing a GDB pro= cess=20 > model (i.e. separate address spaces) with actual OS processes. Well, if gdb can tell them apart... My concern is that gdb's process model implementation was likely not done with the qemu scenario in mind (otherwise we would talk about "gdb thread model vs. address space model"= ). >=20 > The point is that each CPU has its own distinct virtual address space. = GDB=20 > assumes that all threads use the same memory map. To handle these disti= nct=20 > address spaces you need to model CPUs as processes. Your thread hack is= =20 > dependent on, and limited to, address ranges that happen to mapped the = same=20 > on all CPUs. This may be sufficient for simple linux kernel debugging, = but=20 > fails very rapidly when you start trying to do anything clever. So far it hasn't because the thread model implementation is a bit smarter than a "hack". However, you still don't tell us what prevents to _add_ the multiprocess support to qemu once gdb or some other debugger can handle it according to our needs. It is an _addon_ feature to the gdb protocol anyway, and qemu will have to check if the frontend supports it. If not, qemu could fall back to the thread model to allow at least "basic" debugging and would not have to tell the frontend "sorry, I'm too smart for you". >=20 >> You cannot simply assign some CPU n to a virtual process n because the= >> mapping you see on that CPU at some point in time may next pop up on >> some other CPU - and vice versa. You start to make gdb believe it sees= >> consistent processes while you have no clue at all about the schedulin= g >> of your guest. So what do you gain? >=20 > Mapping current CPU state to an OS process is the debugger's problem. A= =20 > sufficiently smart debugger is able to interpret the OS process table, = and=20 > match that to the address space that's present on a particular CPU. I d= on't=20 > think GDB is capable of doing this right now, but I've seen it done in = other=20 > debuggers. So this is still a future requirement on qemu, no? Let's assume we had multiprocess support implemented in qemu already. Would I still be able to debug the "corner case" Linux without additional pain? >=20 >> I can tell you what you loose: If gdb starts to think that there are n= >> separate processes, you will have to set separate breakpoints as well.= >> Bad. And if some breakpoint assigned to process n suddenly hits you on= >> process (CPU) m, only chaos is the result. E.g. kvm would re-inject it= >> as guest-originated. Even worse. >=20 > You need to use multi-process breakpoints. Does gdb provide them already? Or is there some other free debuggers that do so? >=20 > An OS aware debugger will take care of migrating userspace breakpoints = when OS=20 > context switches occur. >=20 >> There was zero practical need for this so far. But maybe you can >> describe a _concrete_ debugging use case and the related steps in gdb = - >> based on a potential process interface. I'm surely willing to learn >> about it if there is really such a great practical improvement feasibl= e. >> What will be the user's benefit? >=20 > In embedded systems it's fairly common to run entirely separate operati= ng=20 > systems on different cores. e.g. you may run linux on one core and a RT= OS or=20 > dedicated codec engine on the other. Accepted, that can be a valid use case. Right now the debugger could already handle this scenario /wrt soft breakpoints by leaving the focus on those CPUs for which it has the code image. >=20 > The rest of my examples are hypothetical. I don't have actual examples,= =20 > however it's things that I know people are interested in, and in some c= ases=20 > actively working on. GDB already has a python plugin interface, though = > currently there aren't any useful hooks for doingn OS awareness stuff. >=20 > I'm not sure offhand how highmem mappings work. Are these per-cpu or gl= obal? > My guess is linux makes them global, but I can certainly imagine them b= eing=20 > per-cpu. highmem is global. I'm not sure if anyone will bother changing this in the future. Multicore CPU need an increasing amount of memory, thus generally come with a sufficiently large virtual address spaces. I admit: If you add OS awareness to the debugger or if you have a fixed CPU schedule, the multiprocess protocol extension can be useful as it allows to direct break/watchpoints to certain CPUs. My suggestion still stands: Add multiprocess support on top of the thread model, but keep threads as foundation. The former is upcoming technology while the latter already covers most of todays' kernel debugging scenarios without problems. But I do have my problems with providing interfaces _only_ for users still under development, neglecting what is already possible with todays' versions. Right now we face a similar issue with x86 due to gdb not yet being as far as a certain change to gdbstub assumed. I'm working on this, but it was confirmed by gdb people that there is easy quick fix. And that currently leaves qemu unusable for certain scenarios unless you patch it. So please focus on what is available today - and please let us merge this patch. vCont is mandatory for the multiprocess feature anyway, just the thread-id encoding will vary. Jan --------------enig6BAD41568F1F6A0CE7FF08D3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAklw3xEACgkQniDOoMHTA+kWpwCeMQgQx5weCe6lFU9DWx1KYjyF P4cAoIAWn4dCeGfJ2+m9DCShLh2+CA7D =8BUC -----END PGP SIGNATURE----- --------------enig6BAD41568F1F6A0CE7FF08D3--