From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71561 invoked by alias); 18 Jan 2016 15:47:52 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 71544 invoked by uid 89); 18 Jan 2016 15:47:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=filling, fetched, theyll, they'll X-HELO: mail-wm0-f51.google.com Received: from mail-wm0-f51.google.com (HELO mail-wm0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 18 Jan 2016 15:47:50 +0000 Received: by mail-wm0-f51.google.com with SMTP id b14so129365143wmb.1 for ; Mon, 18 Jan 2016 07:47:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-type:content-disposition:user-agent; bh=XK56MYYGVnsvAnHUqPfwATErBpSsh5SLUrZgE9/KDI4=; b=f1wxp3iUMtQtMyT0rgilyFp/ZA0ZXSs2QQAHqj+cTkmigJ0PYv3oCIpyxqqXHby/1r 4sdLptx0cLZ0qbT7cs8Fw5us80Q+qW+hh4UdrflTq8WG+gGxmu7wxsC7bc7FiU7i4Bze dpnMSVtzjtVyB7X/S9Q6D+ak1j8Huzt7CiT7KPxxdTKNcuXSaCavXdI/uT4FA13yEy4T CCSmcLS0D5/TeCGeoTdr6ukMzKSRcYZxv9OIzARlyJ4rxiS84B9Yj8dpdv8j3hESlvHw LMB/m3VjMxgtOJd3EQDkgvYFNdWDokZcAjVOYXYx8MbCvlwvq4pJl9GZ1IJvZLyQat8k 8dnA== X-Gm-Message-State: AG10YOTHJENt8O4uw1X41W5roM+3dxT7iD4Plv+Aj3SrJGGjOrO/s2haxXEHwlunQP1VOA== X-Received: by 10.28.148.140 with SMTP id w134mr14669093wmd.66.1453132066987; Mon, 18 Jan 2016 07:47:46 -0800 (PST) Received: from localhost (TK158115.telekabel.at. [195.34.158.115]) by smtp.gmail.com with ESMTPSA id w23sm16362441wmd.1.2016.01.18.07.47.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jan 2016 07:47:46 -0800 (PST) Date: Mon, 18 Jan 2016 15:47:00 -0000 From: Andrew Burgess To: gdb@sourceware.org Subject: [RFC] remote protocol and breakpoint shadow buffers Message-ID: <20160118154745.GS4242@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00026.txt.bz2 I have a target, where, in order to create the frame id, I end up having to take a peek at the target code memory. This target is only accessed over the remote protocol, and makes use of the Z0/z0 packets to insert and remove breakpoints. Now, compute_frame_id is called from handle_signal_stop, which is called from handle_inferior_event, which is called from fetch_inferior_event. The problematic thing for me is that handle_inferior_event is called before the breakpoints are removed from the inferior, which happens within normal_stop. So, in my target's compute_frame_id handler, when I read target code memory with target_read_memory the software breakpoints are still in place, and at the moment, gdb does not store the memory being replaced with a breakpoint in the breakpoint's shadow buffer, so the breakpoint shadow mechanism does not save me. I have a number of questions: 1. In breakpoint_xfer_memory, when we find a breakpoint that overlaps the memory region being fetched, but that does not have a shadow buffer, should we not at least warn the user that they are about to see something they probably don't expect? Maybe we'd need to filter any such warning to only apply to breakpoints that alter target memory. 2. Should the Z0/z0 packet be filling in the shadow buffer? I don't think there's a nice way to do this in general, as the Z0 packet relies on the remote end to pick, and place a software breakpoint, there's no way to know for sure how much memory was overwritten. Maybe the OK reply to a Z0 packet should include information about what was hidden so that the shadow buffer could be filled correctly? 3. Trying to access target code memory as part of the compute_frame_id isn't that uncommon, I believe that (to pick two random targets) amd64, and arm both do this. Here's the call graph for amd64, arm is similar: amd64_frame_this_id -> amd64_frame_cache -> amd64_frame_cache_1 -> amd64_analyze_prologue -> amd64_analyze_stack_align However, I don't think the targets amd64/arm are actually at risk in most cases, as they'll usually be using the DWARF unwinder, which should circumvent this issue, however, some code without an attached DWARF unwinder should hit this issue. Does anyone have any suggestions as to the right way forward for resolving this issue? If seems like my choices are: (a) Extend Z0 to allow filling of the shadow buffer. (b) Have breakpoints be removed earlier in the stop process so that I don't have to worry about the shadow buffer at all. (c) Try very hard to rewrite my target to NOT access code memory in order to build the frame id. Don't worry about other targets that are possibly also broken in the same way. Any advice appreciated. Thanks, Andrew