[Bug gdb/28371] gdb: watchpoint for local variable doesn't work on RISC-V

["wilson at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28371

Jim Wilson <wilson at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu.org

--- Comment #2 from Jim Wilson <wilson at gcc dot gnu.org> ---
I can reproduce natively on an Unmatched with the SiFive OpenEmbedded distro. 
Looking at the gcc and clang output.  I see that the epilogue for func2 in the
gcc output is

        ld      s0,24(sp)
        .cfi_restore 8
        .cfi_def_cfa 2, 32
        addi    sp,sp,32
        .cfi_def_cfa_offset 0
        jr      ra
        .cfi_endproc

And the epilogue for func2 in the clang output is

        ld      s0, 16(sp)                      # 8-byte Folded Reload
        ld      ra, 24(sp)                      # 8-byte Folded Reload
        addi    sp, sp, 32
        ret
.Ltmp3:
.Lfunc_end1:
        .size   func2, .Lfunc_end1-func2
        .cfi_endproc

So the clang output has no unwind info for epilogues.  I believe that is a
known problem with clang.

Somehow this lack of epilogue unwind info is confusing gdb, and it thinks that
the variable q has gone out of scope when it sees the frame pointer popped from
the stack without corresponding unwind info.  This makes some sense, since gdb
has to parse the frame to find the local q in the parent function, and if the
unwind info is wrong it won't be able to do that.

I don't know if this can be fixed in gdb.  It can certainly be fixed in clang
by emitting unwind info for function epilogues.

Also note that if you put a breakpoint in the func2 epilogue and type the "up"
command, this works with the gcc output, taking you to main, but fails in the
clang output, taking you to __libc_start_call_main which is a glibc function. 
Epilogue unwind info is needed for this to work right also.

This whole mess is probably complicated by the fact that we don't have hardware
watchpoints (except with openocd), so we have to single step through code and
check for a change to q after every instruction.  If we had hardware
watchpoints, the watchpoint for q would work correctly.  Without hardware
watchpoints, we need function epilogue unwind info to be correct.

-- 
You are receiving this mail because:
You are on the CC list for the bug.