From owner-freebsd-hackers Fri Mar 1 23:23:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from tonnant.cnchost.com (tonnant.concentric.net [207.155.248.72]) by hub.freebsd.org (Postfix) with ESMTP id 96AAC37B41B for ; Fri, 1 Mar 2002 23:23:11 -0800 (PST) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by tonnant.cnchost.com id CAA16024; Sat, 2 Mar 2002 02:22:48 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200203020722.CAA16024@tonnant.cnchost.com> To: Peter Wemm Cc: Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: Missing PT_READ_U In-reply-to: Your message of "Fri, 01 Mar 2002 21:43:22 PST." <20020302054322.874273BAC@overcee.wemm.org> Date: Fri, 01 Mar 2002 23:22:47 -0800 From: Bakul Shah 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 > 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. Now that I think about it, ups will need to be fixed up since the ability to write registers is lost with PT_WRITE_U gone (have to use PT_SETREGS). If you want to put PT_WRITE_U back in 4.5, I wouldn't complain;-) > Incidently, PT_READ_U didn't actually work for the case where the > signal handlers were shared between rfork()'ed processes. Hmm... Probably neither does ups:-) > Do you have any suggestions as to how PT_GET/SETSIGSTATE should look and > feel? UPS's requirements seem pretty trivial (ie: return the handler > for a given signal number), but that feels a bit minimalistic given that > we have flags and a mask per signal as well. There is also the signal > mask as well (masks are 128 bit). I just copy struct sigacts in my code for this. There is no PT_SETSIGSTATE (that would require a whole bunch of checking for very little gain). > On the other hand, maybe we should just keep it simple for ptrace() since > the API is so limited. There is time to think through API changes for 5.x. Reporting signal state is a small part of this! Some random thoughts: - 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. - 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!). - 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] - 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. - 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]. - All this gets somewhat trickier (or impossible) to implement if you allow threads to run on multiple processors! - 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message