From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31536 invoked by alias); 4 Oct 2013 11:22:28 -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 31521 invoked by uid 89); 4 Oct 2013 11:22:28 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 04 Oct 2013 11:22:28 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r94BMMOH029963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Oct 2013 07:22:23 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r94BMLMU022706; Fri, 4 Oct 2013 07:22:21 -0400 Message-ID: <524EA4EC.3020103@redhat.com> Date: Fri, 04 Oct 2013 11:22:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Jose E. Marchesi" CC: "Tedeschi\, Walfred" , "gdb-patches@sourceware.org" Subject: Re: [PATCH][SPARC64] Fix breakpointing in syscalls other than sigreturn References: <87ioxradrb.fsf@oracle.com> <871u4fab3d.fsf@oracle.com> In-Reply-To: <871u4fab3d.fsf@oracle.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-10/txt/msg00139.txt.bz2 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 > > 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: > ... > 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