Re: [PATCH][SPARC64] Fix breakpointing in syscalls other than sigreturn

[Pedro Alves <palves@redhat.com>]

Hi Jose!

On 09/23/2013 03:04 PM, Jose E. Marchesi wrote:

> 
> I noticed that watchpoints were not surviving ld.so.  Consider this test
> program:
> 
>   int jorl;
> 
>   int main ()
>   {
>     jorl = 20;
>     return 0;
>   }
> 
> If you set a watchpoint to watch writes to the variable 'jorl' and then
> 
>   [jemarch@jemarch1 ~]$ gdb foo
>   GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.0.2.el6)
>   Copyright (C) 2010 Free Software Foundation, Inc.
>   License GPLv3+: GNU GPL version 3 or later
>   <http://gnu.org/licenses/gpl.html>
>   This is free software: you are free to change and redistribute it.
>   There is NO WARRANTY, to the extent permitted by law.  Type "show
>   copying"
>   and "show warranty" for details.
>   This GDB was configured as "sparc64-redhat-linux-gnu".
>   For bug reporting instructions, please see:
>   <http://www.gnu.org/software/gdb/bugs/>...
>   Reading symbols from /home/jemarch/foo...(no debugging symbols
>   found)...done.
>   (gdb) watch jorl
>   Watchpoint 1: jorl
>   (gdb) run
>   Starting program: /home/jemarch/foo
>   0xfffff8010001c444 in mmap64 () from /lib64/ld-linux.so.2
>   Could not insert single-step breakpoint at 0x1
>   (gdb)
> 
> As described in the patch the problem is that single-stepping over 'ta
> 0x6d' instructions is not working properly.  And the reason is that
> sparc64_linux_step_trap is only intended to be useful when
> single-stepping sigreturn syscalls and must return zero in any other
> case.
> 
> Do you want a test for gdb/testsuite?

This sounds really like a basic use case -- set a watchpoint
on a global, before running the program, and then run the program,
with hardware watchpoints disabled, so that gdb uses software
watchpoints all the way, or IOW, GDB single-steps all the way through
the program's execution, starting at the entry point, up until the
watchpoint triggers.

I'm surprised the testsuite doesn't trip on this already.  E.g.,
gdb.base/watchpoint.exp.  But maybe all tests are only creating
watchpoints after running to main?
If indeed this isn't covered already, then yeah, a test like
that looks to be quite useful to have.  Basically, the test would
just need to make sure hardware watchpoints are disabled, with
"set can-use-hw-watchpoints 0" (or it'd create a watchpoint on something
not memory, like watch $some_convenience_var), and it shouldn't
use "run" directly, so that it works with gdbserver/"target remote"
as well.  I think it could use gdb_start_cmd for the latter.
Actually, gdb.base/watchpoint-hw.exp looks quite almost like what
you'd aim for, except well, it's skipped on software watchpoint targets.

> In that case, what would be the best place where to add the test?  gdb.base?

Yep, that's fine.  You can also adapt or add to an existing case,
if it makes sense.

Thanks,
-- 
Pedro Alves