From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2745 invoked by alias); 8 Nov 2013 08:04:08 -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 2733 invoked by uid 89); 8 Nov 2013 08:04:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: Yes, score=6.4 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPAM_SUBJECT,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mail.bachmann.info Received: from Unknown (HELO mail.bachmann.info) (213.33.91.3) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Nov 2013 08:04:06 +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 rA883sQG026781 for ; Fri, 8 Nov 2013 09:03:54 +0100 Received: from ATFKEX05.bachmann.at ([fe80::d25:361a:b427:cdde]) by atfkex04.bachmann.at ([fe80::e9df:b70d:a4dd:a52d%11]) with mapi id 14.03.0123.003; Fri, 8 Nov 2013 09:03:54 +0100 From: "ILG.Robert" To: "gdb-patches@sourceware.org" Subject: Re: Extending RSP with vCont;n and vCont;f Date: Fri, 08 Nov 2013 08:18:00 -0000 Message-ID: <7E3A266F5548C442BC08FA3038B5197CB68E619D@atfkex05.bachmann.at> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00222.txt.bz2 First of all I have to say "thank you" and I have to withdraw the "vCont"-p= atch.=20 All arguments and problems have been solved with your help! The rest of this mail will explain the actual reason for our problem, will = answer your questions and sums up the solution of handling "read-only" breakpoints. > Sorry for the delayed reply. Now I'm late, but it took some time to trace down the problem. It turned out that we have had some wrong settings concerning the variable = "DECR_PC_AFTER_BREAK". Normally this variable is set to -1 so that the EIP-Address is corrected to= the actual breakpoint address. Our GDB-Stub already delivers the correct EIP-Address so that GDB = was misinterpreting the breakpoints for some special cases. As a consequence GDB directly changed t= he EIP-Register which=20 caused those random problems. One of this special case happened to be at th= e same place as our "read-only" problem so that I accused GDB in vain. Sorry about that! >> On 10/09/2013 07:37 PM, ILG.Robert wrote: >> I haven't been able to trace back the exact problem. If the target denie= s to insert a=20 >> breakpoint for "finish", GDB will crash later while debugging because it= suddenly uses=20 >> rotten addresses. If GDB is not informed about the problem of setting su= ch a=20 >> breakpoints, you can continue debugging without any problem. It looks li= ke as GDB=20 >> contains an incomplete error handling. > I hacked GDB a little to force GDB setting momentary breakpoint on addres= s 0x0 when=20 > command 'finish' is typed. Then, I get:=20 > > (gdb) finish > Run till exit from #0 break_me () at ../../../../git/gdb/testsuite/gdb.ba= se/frame-args.c:35=20 > 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=20 > 35=A0=A0=A0=A0=A0 } > > Looks GDB handles this error well.=A0 Can you see this warning in your ta= rget? Yes, I can see the same output. After the problem of "DECR_PC_AFTER_BREAK" = has been fixed=20 the following output comes along (Hz-Packages and m-Packages removed for be= tter readability): =A0 =A0=A0Sending packet: $Z0,7564605,1#84...Packet received: E02 =A0 =A0=A0Sending packet: $z0,6a9d31f,1#31...Packet received: OK =A0 =A0=A0Sending packet: $vCont?#49...Packet received: vCont;c;C;s;S;t;f;n =A0 Packet vCont (verbose-resume) is supported =A0 =A0=A0Sending packet: $vCont;s:23e5af8#f0...Packet received: OK =A0 =A0=A0Notification received: Stop:T0505:785a3e02;04:5c5a3e02;08:d0e3a90= 6;thread:23e5af8; =A0=A0=A0 Sending packet: $vStopped#55...Packet received: OK =A0=A0=A0 Sending packet: $Z0,6a9d31f,1#11...Packet received: OK =A0=A0=A0 Sending packet: $Z0,7564605,1#84...Packet received: E02 =A0 Warning: =A0 Cannot insert breakpoint 0. =A0 Error accessing memory address 0x7564605: (undocumented errno -1). =A0 cycle () at ugn.c:81 =A0 81=A0=A0=A0=A0=A0 { > >> 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 you= r hardware=20 > has hw breakpoints, GDB or your stub can switch breakpoint to hw breakpoi= nt if the=20 > region is read-only or the address is within your system code. Looks it i= s easier=20 > to do it inside your stub. People who familiar with breakpoint can give c= omments too.=20 Pedro Alves was so kind to point out the already existing solution to handl= e "read-only" breakpoints. Unfortunately I've not been able to implement it yet, as it is too close fo= r our version to be shipped. ".for the GDB side, see "set breakpoint auto-hw on" at: =A0 https://sourceware.org/gdb/onlinedocs/gdb/Set-Breaks.html " Thanks again, Robert