ongoing frysk.proc.ptrace refactoring

ongoing frysk.proc.ptrace refactoring

[Andrew Cagney]

Just a work-in-progress update:

While I've finished restructuring the target specific frysk.proc code 
into separate frysk.proc.corefile, frysk.proc.dummy and 
frysk.proc.ptrace packages there's still a ways to go as the refactoring 
has helped clarify several additional problems with the current code:

-> frysk.proc.Proc and frysk.proc.Task seem to have gained a number of 
fields, such as Task.sig_send, that are very Linux/ptrace centric; 
the'll need to be cleaned up

-> many of the methods, such as frysk.proc.Task.sendContinue, being 
ptrace specific (they do not apply to a corefile proc), can be moved to 
more specific packages

-> rather than split along the lines of "corefile" and "ptrace", a 
better split might be "dead" (you can query a dead proc) and "live" (or 
stateful) (you can observe a live proc), re-consider that once the more 
pressing issues are addressed

I'll be continuing with this.

Andrew

Re: ongoing frysk.proc.ptrace refactoring

[Chris Moller]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

Andrew,

I'd planned to add MemorySpaceByteBuffer.java and commit a few changes
to TestByteBuffer.java in frysk-core/frysk/proc/ptrace later today--is
that going to mung up the stuff you're doing?

Chris

Andrew Cagney wrote:
> Just a work-in-progress update:
>
> While I've finished restructuring the target specific frysk.proc code
> into separate frysk.proc.corefile, frysk.proc.dummy and
> frysk.proc.ptrace packages there's still a ways to go as the
> refactoring has helped clarify several additional problems with the
> current code:
>
> -> frysk.proc.Proc and frysk.proc.Task seem to have gained a number of
> fields, such as Task.sig_send, that are very Linux/ptrace centric;
> the'll need to be cleaned up
>
> -> many of the methods, such as frysk.proc.Task.sendContinue, being
> ptrace specific (they do not apply to a corefile proc), can be moved
> to more specific packages
>
> -> rather than split along the lines of "corefile" and "ptrace", a
> better split might be "dead" (you can query a dead proc) and "live"
> (or stateful) (you can observe a live proc), re-consider that once the
> more pressing issues are addressed
>
> I'll be continuing with this.
>
> Andrew
>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: ongoing frysk.proc.ptrace refactoring

[Andrew Cagney]

Chris,

Adding MemorySpaceByteBuffer won't affect any of this as that side is 
already very clean.  It's in the state-machine (separate) that I've been 
seeing problems.

Thanks for the heads up though,

Andrew

Chris Moller wrote:
> Andrew,
>
> I'd planned to add MemorySpaceByteBuffer.java and commit a few changes
> to TestByteBuffer.java in frysk-core/frysk/proc/ptrace later today--is
> that going to mung up the stuff you're doing?
>
> Chris
>
> Andrew Cagney wrote:
>   
>> Just a work-in-progress update:
>>
>> While I've finished restructuring the target specific frysk.proc code
>> into separate frysk.proc.corefile, frysk.proc.dummy and
>> frysk.proc.ptrace packages there's still a ways to go as the
>> refactoring has helped clarify several additional problems with the
>> current code:
>>
>> -> frysk.proc.Proc and frysk.proc.Task seem to have gained a number of
>> fields, such as Task.sig_send, that are very Linux/ptrace centric;
>> the'll need to be cleaned up
>>
>> -> many of the methods, such as frysk.proc.Task.sendContinue, being
>> ptrace specific (they do not apply to a corefile proc), can be moved
>> to more specific packages
>>
>> -> rather than split along the lines of "corefile" and "ptrace", a
>> better split might be "dead" (you can query a dead proc) and "live"
>> (or stateful) (you can observe a live proc), re-consider that once the
>> more pressing issues are addressed
>>
>> I'll be continuing with this.
>>
>> Andrew
>>
>>     
>
>   

Re: ongoing frysk.proc.ptrace refactoring

[Chris Moller]

[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]

I just committed this stuff.  You should be able to drop
MemorySpaceByteBuffer in as a replacement for AddressSpaceByteBuffer and
get a huge increase in performance in multi-word peeks.

Does anyone need high-speed multi-word pokes?  The StatelessFile class
supports that, but AddressSpaceByteBuffer doesn't, so I didn't include
it in MemorySpaceByteBuffer.  If there's enough popular demand (>= 1
request), I'll hack it in.

Let me know if it blows up in your face...

cm

Chris Moller wrote:
> Andrew,
>
> I'd planned to add MemorySpaceByteBuffer.java and commit a few changes
> to TestByteBuffer.java in frysk-core/frysk/proc/ptrace later today--is
> that going to mung up the stuff you're doing?
>
> Chris
>
> Andrew Cagney wrote:
>   
>> Just a work-in-progress update:
>>
>> While I've finished restructuring the target specific frysk.proc code
>> into separate frysk.proc.corefile, frysk.proc.dummy and
>> frysk.proc.ptrace packages there's still a ways to go as the
>> refactoring has helped clarify several additional problems with the
>> current code:
>>
>> -> frysk.proc.Proc and frysk.proc.Task seem to have gained a number of
>> fields, such as Task.sig_send, that are very Linux/ptrace centric;
>> the'll need to be cleaned up
>>
>> -> many of the methods, such as frysk.proc.Task.sendContinue, being
>> ptrace specific (they do not apply to a corefile proc), can be moved
>> to more specific packages
>>
>> -> rather than split along the lines of "corefile" and "ptrace", a
>> better split might be "dead" (you can query a dead proc) and "live"
>> (or stateful) (you can observe a live proc), re-consider that once the
>> more pressing issues are addressed
>>
>> I'll be continuing with this.
>>
>> Andrew
>>
>>     
>
>   


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: ongoing frysk.proc.ptrace refactoring

[Andrew Cagney]

Chris,

Good question.  The existing code-observer code modifies memory by 
inserting small breakpoint instructions (1 byte on i386, 4 bytes on PPC 
and 8 bytes? on ia64) and going forward will write slightly larger 
chunks (~16 bytes) so efficiency there may be helpful.  Beyond that, 
however, no existing code is attempting large memory writes so 
justification for the change is absent.

Andrew

Chris Moller wrote:
> I just committed this stuff.  You should be able to drop
> MemorySpaceByteBuffer in as a replacement for AddressSpaceByteBuffer and
> get a huge increase in performance in multi-word peeks.
>
> Does anyone need high-speed multi-word pokes?  The StatelessFile class
> supports that, but AddressSpaceByteBuffer doesn't, so I didn't include
> it in MemorySpaceByteBuffer.  If there's enough popular demand (>= 1
> request), I'll hack it in.
>
> Let me know if it blows up in your face...
>
> cm
>
> Chris Moller wrote:
>   
>> Andrew,
>>
>> I'd planned to add MemorySpaceByteBuffer.java and commit a few changes
>> to TestByteBuffer.java in frysk-core/frysk/proc/ptrace later today--is
>> that going to mung up the stuff you're doing?
>>
>> Chris
>>
>> Andrew Cagney wrote:
>>   
>>     
>>> Just a work-in-progress update:
>>>
>>> While I've finished restructuring the target specific frysk.proc code
>>> into separate frysk.proc.corefile, frysk.proc.dummy and
>>> frysk.proc.ptrace packages there's still a ways to go as the
>>> refactoring has helped clarify several additional problems with the
>>> current code:
>>>
>>> -> frysk.proc.Proc and frysk.proc.Task seem to have gained a number of
>>> fields, such as Task.sig_send, that are very Linux/ptrace centric;
>>> the'll need to be cleaned up
>>>
>>> -> many of the methods, such as frysk.proc.Task.sendContinue, being
>>> ptrace specific (they do not apply to a corefile proc), can be moved
>>> to more specific packages
>>>
>>> -> rather than split along the lines of "corefile" and "ptrace", a
>>> better split might be "dead" (you can query a dead proc) and "live"
>>> (or stateful) (you can observe a live proc), re-consider that once the
>>> more pressing issues are addressed
>>>
>>> I'll be continuing with this.
>>>
>>> Andrew
>>>
>>>     
>>>       
>>   
>>     
>
>   

Re: ongoing frysk.proc.ptrace refactoring

[Phil Muldoon]

Chris Moller wrote:
> I just committed this stuff.  You should be able to drop
> MemorySpaceByteBuffer in as a replacement for AddressSpaceByteBuffer and
> get a huge increase in performance in multi-word peeks.
>   

If no-one objects, can it be used in ptrace/LinuxTask.sendrecMemory () 
instead of AddressSpace?

Regards

Phil