From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21479 invoked by alias); 23 Oct 2013 07:19:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 21464 invoked by uid 89); 23 Oct 2013 07:19:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,MIME_BASE64_BLANKS,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail.bachmann.info Received: from mail.bachmann.info (HELO mail.bachmann.info) (213.33.91.3) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Oct 2013 07:19:22 +0000 Received: from atfkex04.bachmann.at (atfkex04.bachmann.at [10.10.10.8]) by mail.bachmann.info (8.14.5/8.14.5) with ESMTP id r9N7J7KJ029409; Wed, 23 Oct 2013 09:19:07 +0200 Received: from atfkex06.bachmann.at ([fe80::f8b1:c064:d390:b714]) by atfkex04.bachmann.at ([fe80::e9df:b70d:a4dd:a52d%11]) with mapi id 14.03.0123.003; Wed, 23 Oct 2013 09:19:07 +0200 From: "ILG.Robert" To: "yao@codesourcery.com" , "palves@redhat.com" CC: "gdb-patches@sourceware.org" Subject: Re: Extending RSP with vCont;n and vCont;f Date: Wed, 23 Oct 2013 07:19:00 -0000 Message-ID: <7E3A266F5548C442BC08FA3038B5197C6844C410@ATFKEX06.bachmann.at> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00707.txt.bz2 QXMgdGhlIHF1ZXN0aW9uIGNvbmNlcm5pbmcgdGhlIHByb3Bvc2VkIHBhdGNo IGhhcyBwYXNzZWQgc2lsZW50bHkgd2l0aGluIHRoZSBtYXNzIG9mIHJlcXVl c3RzLCBJIGRhcmUgdG8gcG9zdCBpdCBhZ2Fpbi4NCg0KSG93IGRvZXMgR0RC IGNvcGUgd2l0aCByZWFkLW9ubHkgY29kZSwgdGhhdCBkb2VzIG5vdCBhbGxv dyB0byBpbnNlcnQgYnJlYWtwb2ludHM/DQoNCkhlcmUgdGhlIHByb2JsZW0g aXMgZGVzY3JpYmVkIGluIG1vcmUgZGV0YWlsOg0KPiBBbGwgdGhlIHNhbWUg ImZpbmlzaCIgaXMgbmVlZGVkIGluIG9yZGVyIHRvIGhhbmRsZSB0aGUgR0RC ICJmaW5pc2giIGNvcnJlY3RseS4gDQo+IFJlbWVtYmVyIHRoYXQgb3VyIHRh cmdldCBjYW5ub3QgaW5zZXJ0IGJyZWFrcG9pbnRzIHRvIHN5c3RlbSBjb2Rl LCBsaWtlIA0KPiBvdGhlciB0YXJnZXRzIGNhbm5vdCBhbHRlciByZWFkLW9u bHkgbWVtb3J5LiBTbyBpZiB5b3UgdHJpZ2dlciB0aGUgc3lzdGVtIA0KPiB0 byBjYWxsIGEgY2FsbC1iYWNrIGZ1bmN0aW9uIG9mIHlvdXIgY29kZSwgeW91 IGNhbm5vdCBzdGVwIGJhY2suIFRoZSBTdGFjayANCj4gd291bGQgbG9vayBs aWtlIHRoaXM6IA0KPiBNeUNvZGUxLS0+U3lzdGVtQ29kZTItLT4uLi4tLT5T eXN0ZW1jb2RlNC0tPk15Q29kZTUuIA0KPiBBcyB5b3UgY2Fubm90IGluc2Vy dCBhIGJyZWFrcG9pbnQgdG8gU3lzdGVtQ29kZTQgdGhlcmUgaXMgbm8gd2F5 IHRvIA0KPiAiZmluaXNoIiB1bnRpbCBNeUNvZGUxLiBJbiBzdWNoIGEgY2Fz ZSBHREIgb3IgdGhlIHRhcmdldCBuZWVkIHRvIHJlYWxpemUgDQo+IHRoYXQg dGhlIGNvZGUgaW4gYmV0d2VlbiBjYW5ub3QgYmUgY29udHJvbGxlZCB3aXRo IGJyZWFrcG9pbnRzIGFuZCANCj4gdGhlcmVmb3JlIHRoZSBicmVha3BvaW50 IG5lZWRzIHRvIGJlIHNldCB0byB0aGUgcmV0dXJuIGFkZHJlc3Mgb2YgTXlD b2RlMSANCj4gLSBza2lwcGluZyBhbGwgY29kZSBpbiBiZXR3ZWVuLiBHREIg ZG9lcyBub3Qgc2tpcCB1bmtub3duIGNvZGUgYXQgdGhlIA0KPiBtb21lbnQs IHNvIHRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHNraXBwaW5nIHVua25vd24g Q29kZSBoYXMgdG8gYmUgZG9uZSANCj4gYnkgR0RCIG9yIGJ5IHRoZSB0YXJn ZXQgKHJlbW90ZSBieSB1c2luZyAiZmluaXNoIikuDQo+DQo+IFNvIHRoZSBy ZWFsIHF1ZXN0aW9ucyBhcmU6DQo+IElzIGl0IGludGVuZGVkIHRvIHNraXAg dW5rbm93bi9yZWFkLW9ubHkgY29kZSBpbiBHREI/DQo+IElmIHllcywgaGFz IGl0IHRvIGJlIHNvbHZlZCB3aXRoaW4gR0RCIG9yIHdpdGhpbiB0aGUgdGFy Z2V0Pw0KDQpUaGFua3MuDQo= >From gdb-patches-return-106595-listarch-gdb-patches=sources.redhat.com@sourceware.org Wed Oct 23 08:16:02 2013 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 2898 invoked by alias); 23 Oct 2013 08:16:01 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 2873 invoked by uid 89); 23 Oct 2013 08:16:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.2 required=5.0 tests=AWL,BAYES_00,GARBLED_BODY autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Oct 2013 08:15:59 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1VYtbf-0004v4-8P from Yao_Qi@mentor.com ; Wed, 23 Oct 2013 01:15:55 -0700 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Oct 2013 01:15:55 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.2.247.3; Wed, 23 Oct 2013 01:15:51 -0700 Message-ID: <52678559.6040004@codesourcery.com> Date: Wed, 23 Oct 2013 08:16:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: ILG.Robert CC: "palves@redhat.com" , "gdb-patches@sourceware.org" Subject: Re: WG: Extending RSP with vCont;n and vCont;f References: <7E3A266F5548C442BC08FA3038B5197C684495C0@ATFKEX06.bachmann.at> <525117AF.60703@codesourcery.com> <7E3A266F5548C442BC08FA3038B5197C68449C77@ATFKEX06.bachmann.at> In-Reply-To: <7E3A266F5548C442BC08FA3038B5197C68449C77@ATFKEX06.bachmann.at> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00708.txt.bz2 Content-length: 3434 Sorry for the delayed reply. On 10/09/2013 07:37 PM, ILG.Robert wrote: > I haven’t been able to trace back the exact problem. If the target denies to insert a breakpoint for "finish", GDB will crash later while debugging because it suddenly uses rotten addresses. If GDB is not informed about the problem of setting such a breakpoints, you can continue debugging without any problem. It looks like as GDB contains an incomplete error handling. > I hacked GDB a little to force GDB setting momentary breakpoint on address 0x0 when command 'finish' is typed. Then, I get: (gdb) finish Run till exit from #0 break_me () at ../../../../git/gdb/testsuite/gdb.base/frame-args.c:35 Warning: Cannot insert breakpoint 0. Cannot access memory at address 0x0 0x080483c8 in break_me () at ../../../../git/gdb/testsuite/gdb.base/frame-args.c:35 35 } Looks GDB handles this error well. Can you see this warning in your target? >>> >>Looks your motivation is for functional purpose, range stepping is not suitable to you. Your generalization doesn't look >>> >>reasonable to me. >>> >>We can have a look at supported actions of vCont, 'c,C,s,S,t,r'. They are quite low-level and primitive. However, in >>> >>your proposal, vCont;n and vCont;f are about "step to a new line" and "step out of this function", why are quite high- >>> >>level to me. > Indeed "Next" can be replaced by "range-stepping". It seems that this might work for us. > > All the same "finish" is needed in order to handle the GDB "finish" correctly. Remember that our target cannot insert breakpoints to system code, like other targets cannot alter read-only memory. So if you trigger the system to call a call-back function of your code, you cannot step back. The Stack would look like this: MyCode1-->SystemCode2-->...-->Systemcode4-->MyCode5. As you cannot insert a breakpoint to SystemCode4 there is no way to "finish" until MyCode1. In such a case GDB or the target need to realize that the code in between cannot be controlled with breakpoints and therefore the breakpoint needs to be set to the return address of MyCode1 - skipping all code in between. GDB does not skip unknown code at the moment, so the question is whether skipping unknown Code has to be done by GDB or by the target (remote by using "finish"). > In your example, if breakpoint can't be set on SystemCode4, I'd like to emit an error instead of setting breakpoint on the return address to MyCode1. Otherwise, the meaning of "finish" command is changed. > By the way these RSP commands are not as high level as you think they are. "Next" does not skip a whole line. It only skips a possible function call. Such no DWARF2 information is needed - only the stack and the a few assembler instructions need to be evaluated. > > So the real questions are: Here are my answers, and other people may have their answers too. > Is it intended to skip unknown/read-only code in GDB? IMO, it is not right to skip unknown/read-only code for command "finish". > If yes, has it to be solved within GDB or within the target? > Generally, hardware breakpoints can be used for read-only regions. If your hardware has hw breakpoints, GDB or your stub can switch breakpoint to hw breakpoint if the region is read-only or the address is within your system code. Looks it is easier to do it inside your stub. People who familiar with breakpoint can give comments too. -- Yao (齐尧)