From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98309 invoked by alias); 26 Mar 2018 11:38:10 -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 97351 invoked by uid 89); 26 Mar 2018 11:38:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=1, HContent-Transfer-Encoding:8bit X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Mar 2018 11:38:09 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C194F4023141; Mon, 26 Mar 2018 11:38:07 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 29029D7DFA; Mon, 26 Mar 2018 11:38:06 +0000 (UTC) Subject: Re: [RFA v2] (x86) Fix watchpoint using hardware breakpoint for some distro To: Xavier Roirand , gdb-patches@sourceware.org References: <1521209212-11264-1-git-send-email-roirand@adacore.com> <9c7c8586-2940-bea9-d3fb-a13b0d38a32e@adacore.com> <736c9dbb-4583-c425-f20f-fd3bc5cf84e8@adacore.com> Cc: brobecker@adacore.com From: Pedro Alves Message-ID: <38205bbb-35c0-c512-0d2c-df0fe9596b4f@redhat.com> Date: Mon, 26 Mar 2018 11:38:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <736c9dbb-4583-c425-f20f-fd3bc5cf84e8@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-03/txt/msg00527.txt.bz2 On 03/21/2018 04:17 PM, Xavier Roirand wrote: > Hello Pedro, > > Le 3/20/18 à 4:11 PM, Pedro Alves a écrit : >> On 03/20/2018 02:28 PM, Xavier Roirand wrote: >> Hmm, that's TRAP_BRKPT nowadays.  What was '1' supposed to mean in >> kernels of such vintage?  What was it's symbolic name back then? > > As far as I can see in header file (/usr/include/bits/siginfo.h), > this is the same value, it's: > > TRAP_BRKPT = 1,        /* Process breakpoint.  */ > >> In the table in linux-ptrace.h, we see that modern kernels report >> TRAP_BRKPT/1 for the "single-stepping a syscall" case.  What do >> those older kernels report in that case then? > > When "single-stepping" syscall, the same value (TRAP_BRKPT) is > reported. > >> What do those kernels report for hardware _breakpoints_?  Is it 1 too? > > Yes, I've checked this and it's 1 also. > >> Wondering whether we should make GDB_ARCH_IS_TRAP_HWBKPT return >> true for 1 too... >> >> Please provide a more complete picture. >> > > Is it enough or do you think I need to provide more info ? > Earlier you said that TRAP_HWBKPT was the only case that was different from current kernels, but turns out that's not accurate. And now I'm left wondering what do those kernels report for the other cases you haven't confirmed yet, like hw breakpoints, software breakpoints, and regular single steps. We need a complete picture to figure out what the best fix is. E.g., if hw breakpoints and watchpoints report the same si_code, how do hw breakpoints work with your patch? Thanks, Pedro Alves