From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21323 invoked by alias); 19 Sep 2010 11:39:14 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 21312 invoked by uid 22791); 19 Sep 2010 11:39:13 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_40,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org MIME-Version: 1.0 Date: Sun, 19 Sep 2010 11:39:00 -0000 Message-ID: Subject: running multi-process in lockstep with python From: Matt Rice To: Project Archer Content-Type: multipart/mixed; boundary=001636e903105e804f04909b3e53 X-SW-Source: 2010-q3/txt/msg00202.txt.bz2 --001636e903105e804f04909b3e53 Content-Type: text/plain; charset=ISO-8859-1 Content-length: 606 this could use a fair amount of polish its probably not going to get unless you guys are interested in including it, then i would try and clean up the magic numbers into set/show commands, e.g. using an itset and other stuff. anyhow i think it shows off 2 of the newer features of gdb in my tests lockstep1 foo increments to 10 or so and lockstep2 foo increments to 5 then back to 0. execution continues until reaching 6, 4. where it hands control back to the user with both inferiors stopped. now if it only could debug i386 + x86_64 simultaneously i'd be set probably a twisted version comming up :/ --001636e903105e804f04909b3e53 Content-Type: application/octet-stream; name="lockstep.gdb" Content-Disposition: attachment; filename="lockstep.gdb" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ge9tlycj0 Content-length: 297 c2V0IHBhZ2luYXRpb24gb2ZmCgpzb3VyY2UgbG9ja3N0ZXAucHkKCmFkZC1p bmZlcmlvciAtZXhlYyBsb2Nrc3RlcDEKaW5mZXJpb3IgMgpicmVhayBmb28g CmNvbW1hbmRzCnNpbGVudApzZXQgJHgxID0gaSAKZW5kCnJ1bgoKYWRkLWlu ZmVyaW9yIC1leGVjIGxvY2tzdGVwMgppbmZlcmlvciAzIApicmVhayBmb28g CmNvbW1hbmRzCnNpbGVudApzZXQgJHgyID0gaSAKZW5kCnJ1bgo= --001636e903105e804f04909b3e53 Content-Type: application/octet-stream; name="lockstep.py" Content-Disposition: attachment; filename="lockstep.py" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ge9tn2jw1 Content-length: 1399 cnVuX29uX21hdGNoID0gImNvbnRpbnVlIgpydW5fb25fZG9udF9tYXRjaCA9 ICIiIAoKCmRlZiBkb0xvY2tTdGVwICgpOgoJZ2xvYmFsIHJ1bl9vbl9tYXRj aAoJZ2xvYmFsIHJ1bl9vbl9kb250X21hdGNoCglpbmZlcmlvcnMgPSBkaWN0 KCkKCWZvciBpbmYgaW4gZ2RiLmluZmVyaW9ycygpOgoJICBpZiBpbmYubnVt ID4gMToKCSAgICBpbmZlcmlvcnNbaW5mLm51bV0gPSBpbmYKCglwcmludChp bmZlcmlvcnMpCgl0aHIxID0gaW5mZXJpb3JzWzJdLnRocmVhZHMoKVswXQoJ dGhyMiA9IGluZmVyaW9yc1szXS50aHJlYWRzKClbMF0KCXdoaWxlIHRocjEu aXNfcnVubmluZygpID09IFRydWUgb3IgdGhyMi5pc19ydW5uaW5nKCkgPT0g VHJ1ZToKCSAgY29udGludWUKCQoJeDEgPSBnZGIucGFyc2VfYW5kX2V2YWwo IiR4MSIpCgl4MiA9IGdkYi5wYXJzZV9hbmRfZXZhbCgiJHgyIikKCWlmIHgx ID09IHgyOgoJICBnZGIuZXhlY3V0ZSgiaW5mZXJpb3IgMiIpCgkgIGdkYi5l eGVjdXRlKHJ1bl9vbl9tYXRjaCkgCgkgIGdkYi5leGVjdXRlKCJpbmZlcmlv ciAzIikKCSAgZ2RiLmV4ZWN1dGUocnVuX29uX21hdGNoKQoJICByZXR1cm4g MQoJZWxzZToKCSAgZ2RiLmV4ZWN1dGUoImluZmVyaW9yIDIiKQoJICBnZGIu ZXhlY3V0ZShydW5fb25fZG9udF9tYXRjaCkKCSAgZ2RiLmV4ZWN1dGUoImlu ZmVyaW9yIDMiKQoJICBnZGIuZXhlY3V0ZShydW5fb25fZG9udF9tYXRjaCkK CSAgcmV0dXJuIDAKCgpjbGFzcyBMb2Nrc3RlcCAoZ2RiLkNvbW1hbmQpOgoJ IiIicnVucyBnZGIgY29udGludWUgaW4gMiBpbmZlcmlvcnMgdW50aWwgJHgx ICE9ICR4Mi4iIiIKICAgICAKCWRlZiBfX2luaXRfXyAoc2VsZik6CgkgICBz dXBlciAoTG9ja3N0ZXAsIHNlbGYpLl9faW5pdF9fICgibG9ja3N0ZXAiLCBn ZGIuQ09NTUFORF9PQlNDVVJFKQogICAgIAoJZGVmIGludm9rZSAoc2VsZiwg YXJnLCBmcm9tX3R0eSk6CgkgICB3aGlsZSBkb0xvY2tTdGVwKCkgPT0gMToK CSAgICAgY29udGludWUKCgkgICByZXR1cm4gMApMb2Nrc3RlcCAoKQo= --001636e903105e804f04909b3e53--