On Tue, Oct 4, 2016 at 2:08 PM, Andreas Fritiofson <
andreas.fritiof...@gmail.com> wrote:
> It easier to test on different targets if we have an actual patch to try.
> That said, I fear it will not get a lot of testing as you'd probably have
> to be affected by this corner case to bother.
>
> I don't really follow the logic that GDB can't know which bp/wp was hit.
> Is it because the halt $pc is so close to the other breakpoint? How close
> must they be to trigger this special casing?
>
Looking in more detail, it appears to only affect targets that (in
gdb) set_gdbarch_decr_pc_after_break to some value. This does *not* include
ARM and MIPS (which I assume are the most popular OpenOCD targets). The
special case happens if the reported PC minus the decrement value is an
address where a breakpoint is set.
I'm investigating if RISC-V really needs this set to 4. If it does, maybe I
can work around it by modifying the OpenOCD RISC-V code to add 4 to the PC.
If we advertise swbreak in qSupported, won't we also have to actually send
> swbreak in gdb_signal_reply()? Currently we only send the watchpoint stop
> reasons. We'd need some mechanism to determine whether to send hwbreak or
> swbreak. Hopefully this can be done generically (like looking through the
> list of HW breakpoins and if none match $pc then it's a SW breakpoint
> perhaps).
>
Empirically the only change required is the one in my original mail. It
does seem good to tell gdb explicitly that a software breakpoint was hit,
but the problem goes away without doing it.
Looking at gdb_signal_reply(), the obvious implementation is to add a
debug_reason that unambiguously specifies a software breakpoint. Targets
that run into this problem can start using it, while for others everything
will keep working as expected.
Tim
>
> /Andreas
>
>
> On Tue, Oct 4, 2016 at 9:47 PM, Tim Newsome <t...@sifive.com> wrote:
>
>> Does anybody have an opinion here? Should I just submit the simple "fix"
>> into gerrit and have the discussion there?
>>
>> Tim
>>
>> On Thu, Sep 22, 2016 at 12:25 PM, Tim Newsome <t...@sifive.com> wrote:
>>
>>> I ran into the following problem, debugging this:
>>>
>>> 8000036c <just_before_read_loop>:
>>> 8000036c: 01000393 li t2,16
>>>
>>> 80000370 <read_loop>:
>>> 80000370: 00052303 lw t1,0(a0)
>>>
>>> Set a software breakpoint on just_before_read_loop, and run to it. Then
>>> set a hardware watchpoint on the address in a0. Tell gdb to continue.
>>> Gdb clears breakpoints and single steps to get past the software
>>> breakpoint. Then it sets all breakpoints again, and tells the target to
>>> resume. The target halts at read_loop because the watchpoint is hit, and
>>> reports a trap at 0x80000370. gdb however, then forcibly writes back the pc
>>> to 0x8000036c. The code for this behavior in gdb is in
>>> adjust_pc_after_break() (infrun.c). I didn’t follow that code in detail,
>>> but it seems to come down to gdb decrementing the PC because it’s not sure
>>> whether the software breakpoint or the watchpoint was hit.
>>>
>>> If OpenOCD tells gdb that it can tell the difference between the two,
>>> then this code is bypassed and everything works as I expect. OpenOCD can do
>>> that by adding swbreak+ to the reply to qSupported as follows:
>>>
>>> --- a/src/server/gdb_server.c
>>> +++ b/src/server/gdb_server.c
>>> @@ -2357,7 +2357,7 @@ static int gdb_query_packet(struct connection
>>> *connection,
>>> &buffer,
>>> &pos,
>>> &size,
>>> -
>>> "PacketSize=%x;qXfer:memory-map:read%c;qXfer:features:read%c;QStartNoAckMode+",
>>> +
>>> "PacketSize=%x;qXfer:memory-map:read%c;qXfer:features:read%c;QStartNoAckMode+;swbreak+",
>>> (GDB_BUFFER_SIZE - 1),
>>> ((gdb_use_memory_map == 1) &&
>>> (flash_get_bank_count() > 0)) ? '+' : '-',
>>> (gdb_target_desc_supported == 1) ? '+' : '-');
>>>
>>> My question is: is this safe for all targets? If it is, this is an easy
>>> change. If not, I’ll have to invent some mechanism for targets to let the
>>> gdb_server layer know what should be returned. If that’s required, are
>>> there any guidelines I should follow?
>>>
>>> My target is RISC-V, which I’m working on implementing OpenOCD support
>>> for. I imagine this same issue exists on other targets as well.
>>>
>>> Thank you,
>>> Tim
>>>
>>>
>>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
