From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25631 invoked by alias); 10 Nov 2007 05:20:42 -0000 Received: (qmail 25596 invoked by uid 22791); 10 Nov 2007 05:20:33 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 10 Nov 2007 05:20:30 +0000 Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id lAA5KRr3004449 for ; Fri, 9 Nov 2007 21:20:27 -0800 Received: from ug-out-1314.google.com (ugeo4.prod.google.com [10.66.166.4]) by zps77.corp.google.com with ESMTP id lAA5KQLD016924 for ; Fri, 9 Nov 2007 21:20:26 -0800 Received: by ug-out-1314.google.com with SMTP id o4so522308uge for ; Fri, 09 Nov 2007 21:20:26 -0800 (PST) Received: by 10.67.195.14 with SMTP id x14mr112096ugp.1194672025743; Fri, 09 Nov 2007 21:20:25 -0800 (PST) Received: by 10.67.21.14 with HTTP; Fri, 9 Nov 2007 21:20:25 -0800 (PST) Message-ID: Date: Sat, 10 Nov 2007 05:20:00 -0000 From: "Douglas Evans" To: gdb@sourceware.org Subject: Re: linux-thread-db.c not only caller of add_thread, -> gdb segv In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_19397_31669679.1194672025736" References: <20071109140225.GA32113@caradoc.them.org> <20071110032558.GA19831@caradoc.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00080.txt.bz2 ------=_Part_19397_31669679.1194672025736 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 1321 On Nov 9, 2007 7:40 PM, Douglas Evans wrote: > I suspect it's a matter of degrees (so to speak) or word choice (apologies). > Until MAY_FOLLOW_EXEC is true for linux I'd expect gdb to return control > to the user when an exec() happens. > Am I wrong in thinking gdb will lose control across the exec()? I guess what gdb does for an exec() when MAY_FOLLOW_EXEC==0 is at least partially a matter of taste or definition. Running some experiments I can see that I can control (e.g. single step) the "new" process after the exec but the symbol info is all wrong if I exec() a different program. It didn't take much to get gdb to follow the exec'ing of toy programs. So setting aside a discussion of what MAY_FOLLOW_EXEC==0 really means on linux, how much work remains to support MAY_FOLLOW_EXEC==1? With this patch I can step across the exec from test-exec1.c to test-exec2.c. IWBN if gdb remembered the original program so that if I run it again, gdb reruns test-exec1.x and not test-exec2.x. This is not a real patch, just an experiment. I had to comment out the call to target_mourn_inferior to avoid a hang in gdb (and even a hang in gdb of gdb). Perhaps some aspect of mourning is required here, but just not a full-blown one. Any ideas what it would take to properly support MAY_FOLLOW_EXEC==1? ------=_Part_19397_31669679.1194672025736 Content-Type: text/plain; name=may-follow-exec-play.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_f8too8z10 Content-Disposition: attachment; filename=may-follow-exec-play.txt Content-length: 4214 SW5kZXg6IGluZnJ1bi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZp bGU6IC9jdnMvc3JjL3NyYy9nZGIvaW5mcnVuLmMsdgpyZXRyaWV2aW5nIHJl dmlzaW9uIDEuMjUwCmRpZmYgLXUgLXAgLXIxLjI1MCBpbmZydW4uYwotLS0g aW5mcnVuLmMJMiBOb3YgMjAwNyAxNDo0NzoyOCAtMDAwMAkxLjI1MAorKysg aW5mcnVuLmMJMTAgTm92IDIwMDcgMDQ6NTg6MTAgLTAwMDAKQEAgLTEwOCw2 ICsxMDgsNyBAQCBzdGF0aWMgcHRpZF90IHByZXZpb3VzX2luZmVyaW9yX3B0 aWQ7CiAvKiBUaGlzIGlzIHRydWUgZm9yIGNvbmZpZ3VyYXRpb25zIHRoYXQg bWF5IGZvbGxvdyB0aHJvdWdoIGV4ZWNsKCkgYW5kCiAgICBzaW1pbGFyIGZ1 bmN0aW9ucy4gIEF0IHByZXNlbnQgdGhpcyBpcyBvbmx5IHRydWUgZm9yIEhQ LVVYIG5hdGl2ZS4gICovCiAKKyNkZWZpbmUgTUFZX0ZPTExPV19FWEVDIDEK ICNpZm5kZWYgTUFZX0ZPTExPV19FWEVDCiAjZGVmaW5lIE1BWV9GT0xMT1df RVhFQyAoMCkKICNlbmRpZgpAQCAtMzk2LDcgKzM5Nyw5IEBAIGZvbGxvd19l eGVjIChpbnQgcGlkLCBjaGFyICpleGVjZF9wYXRobmEKICAgICBlcnJvciAo XygiQ291bGQgZmluZCBydW4gdGFyZ2V0IHRvIHNhdmUgYmVmb3JlIGZvbGxv d2luZyBleGVjIikpOwogCiAgIGdkYl9mbHVzaCAoZ2RiX3N0ZG91dCk7Cisj aWYgMAogICB0YXJnZXRfbW91cm5faW5mZXJpb3IgKCk7CisjZW5kaWYKICAg aW5mZXJpb3JfcHRpZCA9IHBpZF90b19wdGlkIChzYXZlZF9waWQpOwogICAv KiBCZWNhdXNlIG1vdXJuX2luZmVyaW9yIHJlc2V0cyBpbmZlcmlvcl9wdGlk LiAqLwogICBwdXNoX3RhcmdldCAodGd0KTsKCgoKW2RqZUBzZWJhIGdkYl0k IGNhdCB0ZXN0LWV4ZWMxLmMKI2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRl IDx1bmlzdGQuaD4KCmludAptYWluIChpbnQgYXJnYywgY2hhciAqYXJndltd KQp7CiAgcHJpbnRmICgidGhpcyBpcyAlc1xuIiwgYXJndlswXSk7CiAgaWYg KGFyZ2MgPT0gMSkKICAgIGV4ZWNsICgiLi90ZXN0LWV4ZWMyLngiLCAiLi90 ZXN0LWV4ZWMyLngiLCAic2Vjb25kIiwgTlVMTCk7CiAgcmV0dXJuIDA7Cn0K CltkamVAc2ViYSBnZGJdJCBjYXQgdGVzdC1leGVjMi5jCiNpbmNsdWRlIDxz dGRpby5oPgojaW5jbHVkZSA8dW5pc3RkLmg+CgpzdGF0aWMgdm9pZApzZWNv bmQgKCkKewogIHByaW50ZiAoInNlY29uZFxuIik7Cn0gIAoKaW50Cm1haW4g KGludCBhcmdjLCBjaGFyICphcmd2W10pCnsKICBwcmludGYgKCJ0aGlzIGlz ICVzXG4iLCBhcmd2WzBdKTsKICBpZiAoYXJnYyA9PSAxKQogICAgZXhlY2wg KGFyZ3ZbMF0sIGFyZ3ZbMF0sICJzZWNvbmQiLCBOVUxMKTsKICBzZWNvbmQg KCk7CiAgcmV0dXJuIDA7Cn0KW2RqZUBzZWJhIGdkYl0kIGdjYyB0ZXN0LWV4 ZWMxLmMgLW8gdGVzdC1leGVjMS54IC1nCltkamVAc2ViYSBnZGJdJCBnY2Mg dGVzdC1leGVjMi5jIC1vIHRlc3QtZXhlYzIueCAtZwpbZGplQHNlYmEgZ2Ri XSQgLi9nZGIgdGVzdC1leGVjMS54CkdOVSBnZGIgNi43LjUwLjIwMDcxMTEw LWN2cwpDb3B5cmlnaHQgKEMpIDIwMDcgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0 aW9uLCBJbmMuCkxpY2Vuc2UgR1BMdjMrOiBHTlUgR1BMIHZlcnNpb24gMyBv ciBsYXRlciA8aHR0cDovL2dudS5vcmcvbGljZW5zZXMvZ3BsLmh0bWw+ClRo aXMgaXMgZnJlZSBzb2Z0d2FyZTogeW91IGFyZSBmcmVlIHRvIGNoYW5nZSBh bmQgcmVkaXN0cmlidXRlIGl0LgpUaGVyZSBpcyBOTyBXQVJSQU5UWSwgdG8g dGhlIGV4dGVudCBwZXJtaXR0ZWQgYnkgbGF3LiAgVHlwZSAic2hvdyBjb3B5 aW5nIgphbmQgInNob3cgd2FycmFudHkiIGZvciBkZXRhaWxzLgpUaGlzIEdE QiB3YXMgY29uZmlndXJlZCBhcyAiaTY4Ni1wYy1saW51eC1nbnUiLi4uCihn ZGIpIGIgbWFpbgpCcmVha3BvaW50IDEgYXQgMHg4MDQ4M2M4OiBmaWxlIHRl c3QtZXhlYzEuYywgbGluZSA3LgooZ2RiKSByClN0YXJ0aW5nIHByb2dyYW06 IC9ob21lL2RqZS9nbnUvc291cmNld2FyZS9oZWFkL29iai9nZGIvdGVzdC1l eGVjMS54IAoKQnJlYWtwb2ludCAxLCBtYWluIChhcmdjPQoxLCBhcmd2PTB4 YmZmZjJlNjQpIGF0IHRlc3QtZXhlYzEuYzo3CjcJICBwcmludGYgKCJ0aGlz IGlzICVzXG4iLCBhcmd2WzBdKTsKKGdkYikgbgp0aGlzIGlzIC9ob21lL2Rq ZS9nbnUvc291cmNld2FyZS9oZWFkL29iai9nZGIvdGVzdC1leGVjMS54CjgJ ICBpZiAoYXJnYyA9PSAxKQooZ2RiKSAKOQkgICAgZXhlY2wgKCIuL3Rlc3Qt ZXhlYzIueCIsICIuL3Rlc3QtZXhlYzIueCIsICJzZWNvbmQiLCBOVUxMKTsK KGdkYikgCkV4ZWN1dGluZyBuZXcgcHJvZ3JhbTogL2hvbWUvZGplL2dudS9z b3VyY2V3YXJlL2hlYWQvb2JqL2dkYi90ZXN0LWV4ZWMyLngKd2FybmluZzog VGVtcG9yYXJpbHkgZGlzYWJsaW5nIGJyZWFrcG9pbnRzIGZvciB1bmxvYWRl ZCBzaGFyZWQgbGlicmFyeSAiL2xpYi9saWJjLnNvLjYiCgpCcmVha3BvaW50 IDEsIG1haW4gKGFyZ2M9CjIsIGFyZ3Y9MHhiZjg0OGVmNCkgYXQgdGVzdC1l eGVjMi5jOjEzCjEzCSAgcHJpbnRmICgidGhpcyBpcyAlc1xuIiwgYXJndlsw XSk7CihnZGIpIAp0aGlzIGlzIC4vdGVzdC1leGVjMi54CjE0CSAgaWYgKGFy Z2MgPT0gMSkKKGdkYikgCjE2CSAgc2Vjb25kICgpOwooZ2RiKSAKc2Vjb25k CjE3CSAgcmV0dXJuIDA7CihnZGIpIGMKQ29udGludWluZy4KClByb2dyYW0g ZXhpdGVkIG5vcm1hbGx5LgooZ2RiKSByClN0YXJ0aW5nIHByb2dyYW06IC9o b21lL2RqZS9nbnUvc291cmNld2FyZS9oZWFkL29iai9nZGIvdGVzdC1leGVj Mi54IAoKQnJlYWtwb2ludCAxLCBtYWluIChhcmdjPQoxLCBhcmd2PTB4YmY5 ZGE4NTQpIGF0IHRlc3QtZXhlYzIuYzoxMwoxMwkgIHByaW50ZiAoInRoaXMg aXMgJXNcbiIsIGFyZ3ZbMF0pOwooZ2RiKSBuCnRoaXMgaXMgL2hvbWUvZGpl L2dudS9zb3VyY2V3YXJlL2hlYWQvb2JqL2dkYi90ZXN0LWV4ZWMyLngKMTQJ ICBpZiAoYXJnYyA9PSAxKQooZ2RiKSBxClRoZSBwcm9ncmFtIGlzIHJ1bm5p bmcuICBFeGl0IGFueXdheT8gKHkgb3IgbikgeQpbZGplQHNlYmEgZ2RiXSQg Cg== ------=_Part_19397_31669679.1194672025736--