From owner-freebsd-hackers Sat Mar 2 0:14: 5 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id AC81C37B402 for ; Sat, 2 Mar 2002 00:14:00 -0800 (PST) Received: from elischer.org ([64.170.121.0]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GSC007S66VCWX@mta6.snfc21.pbi.net> for freebsd-hackers@FreeBSD.ORG; Sat, 02 Mar 2002 00:14:00 -0800 (PST) Date: Sat, 02 Mar 2002 00:13:31 -0800 From: Julian Elischer Subject: Re: Missing PT_READ_U To: Bakul Shah Cc: Peter Wemm , freebsd-hackers@FreeBSD.ORG Message-id: <3C8089AB.892A6A86@elischer.org> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en, hu References: <200203020722.CAA16024@tonnant.cnchost.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bakul Shah wrote: > > > As the culprit behind PT_READ_U's demise, I'm willing to dive in > > and help here if needed. > > Thanks but Julian sent me a patch for 4.5 that seems to work > with no changes in ups. Would be nice if PT_READ_U is put > back in 4.x. Just a quick comment Peter.. I was thinking we could stuff PT_READ_U back in for 4.x to keep UPS going till we sort out the Ptrace API for 5.0 (which we need to do soon because it's the next stumbling block.) and then retrofit the new interface to 4.6(?) when we know what it is rather than doing it twice.. I know that PT_READ_U is ugly and not really correct for rforked processes but it probably can stay in 4.x for a little without doing any damage. > [...] > - should be able to get at additional registers (SSE etc. on x86). > - I'd just merge access to all registers in one register > space. This allows you to access any special or additional > registers intel/amd may throw at you (ditto for ppc) > without having to add more request codes. This is why > READ_U/WRITE_U were so useful. yes but if we changed the frame layout (which we could have done in the kernel at any time) you lose. > - would be nice if the old interface of just returning one > word was put back even for registers. Typically you access > a very small number in a debugger (more typically never). > - May be for reading registers there is some value in a > read-all register interface but hardly ever for writing. > - Need a way to find out what threads exist and may be in > what state (if 5.x had a u-page, this would be part of > it!). ummm one u page N threads.. that is why U page is dying..much of the information init needs to be duplicated PER thread (in the kernel) > - Need PT_{ATTACH,DETACH,CONTINUE}_THREAD to deal with kernel > threads. Some sort of thread-id would be handy for this. > [But I don't know how you find a particular thread] Threads are transitory from the point of view of the kernel you have just enough threads as you need to run the number of system calls you have outstanding. if you are totally in user space (even on N processors then theoretically you have no threads in the kernel so the kernel has no threads assigned to you. (Actually it has N held to one side reserved for you but theoretically they are only there as a cache. On the other hand the kernel is not informed at all about how many threads are running in the userland. and theoretically the userland thread scheduler might switch through 100 userland threads without entering the kernel once so teh kernel doesn't know if there are 100 or 1 threads defined in userland. All it knows is that when it retunred to userland aftera syscall blocked.. SOMETHING did another syscall.... :-) > - On a breakpoint a number of threads may stop -- if you > allow other threads to proceed while the first thread at a > bkpt is stopped. Need an ability to report this as well as > continue/step any subset of these threads. The whole ptrace interfacestarts to fall apart here. > - Inserting debugging code that is run by a particular thread > and no one else can be tricky [ability to insert code is > one of the strengths of ups]. you'd have to nsert a breakpoint and CONDITIONALLY allow the thread to run the new or old code according to which it was. > - All this gets somewhat trickier (or impossible) to > implement if you allow threads to run on multiple > processors! yep > - If all this is done, it should be not too hard to add > support (in a debugger) for debugging multi-process apps. > - Need to look at how multi-threaded apps are debugged on > other OSes and learn from that as well. > - Need to experiment before settling on an interface. > > -- bakul -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message