Re: Extending RSP with vCont;n and vCont;f

["ILG.Robert" <R.ILG@bachmann.info>]

First of all I have to say "thank you" and I have to withdraw the "vCont"-patch. 
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 the EIP-Register which 
caused those random problems. One of this special case happened to be at the 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 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?
Yes, I can see the same output. After the problem of "DECR_PC_AFTER_BREAK" has been fixed 
the following output comes along (Hz-Packages and m-Packages removed for better readability):
    Sending packet: $Z0,7564605,1#84...Packet received: E02
    Sending packet: $z0,6a9d31f,1#31...Packet received: OK
    Sending packet: $vCont?#49...Packet received: vCont;c;C;s;S;t;f;n
  Packet vCont (verbose-resume) is supported
    Sending packet: $vCont;s:23e5af8#f0...Packet received: OK
    Notification received: Stop:T0505:785a3e02;04:5c5a3e02;08:d0e3a906;thread:23e5af8;
    Sending packet: $vStopped#55...Packet received: OK
    Sending packet: $Z0,6a9d31f,1#11...Packet received: OK
    Sending packet: $Z0,7564605,1#84...Packet received: E02
  Warning:
  Cannot insert breakpoint 0.
  Error accessing memory address 0x7564605: (undocumented errno -1).

  cycle () at ugn.c:81
  81      {

>
>> 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. 

Pedro Alves was so kind to point out the already existing solution to handle "read-only" breakpoints.
Unfortunately I've not been able to implement it yet, as it is too close for our version to be shipped.
".for the GDB side, see "set breakpoint auto-hw on" at:

  https://sourceware.org/gdb/onlinedocs/gdb/Set-Breaks.html
"

Thanks again,
Robert