From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85775 invoked by alias); 26 Oct 2016 14:04:21 -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 85723 invoked by uid 89); 26 Oct 2016 14:04:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_05,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=delegate, H*r:sk:mail-it, H*RU:sk:mail-it, Hx-spam-relays-external:sk:mail-it X-HELO: mail-it0-f53.google.com Received: from mail-it0-f53.google.com (HELO mail-it0-f53.google.com) (209.85.214.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 26 Oct 2016 14:04:19 +0000 Received: by mail-it0-f53.google.com with SMTP id q124so34436729itd.1 for ; Wed, 26 Oct 2016 07:04:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=bN1o3v6YNSh0QZTNQkrc6c+1QOHccpqo+EcbJ1kYbCw=; b=R3gzmtU1Iv1g/8H5F0HAC+hzFSowm6BsgLTuiYh7WE3vhGyBh4ThXwQVgofPWN/yu/ SSNAF+e8VJlTc/sodUDKOYkbZGx7FA3q9jOXNfZBxph7wA4GsZEbb+eIkYZE4z0cQmsL qWKdn1NbKGFRgEhPcSjJLeGQSIjdlldHRJAoyJze79gK2wKyNpi6WWEsP8ieaTF/OIAy CuC9H/kLcnULVsGsyBVCcvJUi9IEJ3cP8eAz/zoOpC2li03cZC2RZZQDKSmaXj6bBj8N UR+6sk865V21ABMVET5Ex03evCzXN5PXV/yk70l1xTJFSL58Wdor89afavq6SZfaZyfQ U7OQ== X-Gm-Message-State: ABUngvfOSXP0XS9uqHDhAwEz561KSDvC67uT24IrP880uZX2y8/3eiCbRh7/1dV/uNz3FxaT1AZNJUtJXXri5A== X-Received: by 10.36.175.83 with SMTP id l19mr6311486iti.48.1477490657953; Wed, 26 Oct 2016 07:04:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.174.16 with HTTP; Wed, 26 Oct 2016 07:04:17 -0700 (PDT) From: Ofir Cohen Date: Wed, 26 Oct 2016 14:04:00 -0000 Message-ID: Subject: False positive permanent breakpoints To: "gdb@sourceware.org" Cc: Ofir Cohen Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00047.txt.bz2 Hello, We have debugging support for code running on the iGPU, and we've encountered something that looks like a limitation of gdb. Problem: gdb freaks out on the iGPU when trying to step over/continue when stopped on a permanent breakpoint. Root-cause: gdb *falsely* identifies some instructions as permanent breakpoints. Details ====== We don't call set_gdbarch_skip_permanent_breakpoint() on our target, so there is no support for stepping over permanent breakpoints. Which is fine since software breakpoints is not something that we support at the moment. While trying to fix the root-cause, i.e. let gdb determine that instruction is indeed a breakpoint instruction, I ran into a wall. Looks like gdb is being too *coarse* for the check (whether it is a breakpoint instruction): if (err || memcmp (buf, bp_opcode (bp), bp_size (bp)) != 0) in validate_inserted_breakpoint() function. I'm saying coarse here because on the iGPU the breakpoint thingy is mandated by a single bit, and does not have a unique *opcode*. Proposed solution ============== Could we abstract (delegate away) this predicate to the _target_ ? Perhaps setting a default handler for other targets. Thanks, Ofir