Re: Oh dear. I regret to inform you that commit 4ee89e903de920496a69c01df70db13a70a2a0be might be unfortunate

[Stephen Roberts <Stephen.Roberts@arm.com>]

Apologies, I'm looking into this as a matter of urgency. It appears that my patch has caused the indentation of the following block to become incorrect.

Sorry, 
Stephen R.

---------
From: gdb-buildbot@sergiodj.net <gdb-buildbot@sergiodj.net>
Sent: 20 March 2018 14:14
To: Stephen Roberts; gdb-patches@sourceware.org
Subject: Oh dear. I regret to inform you that commit 4ee89e903de920496a69c01df70db13a70a2a0be might be unfortunate
  

My lords, ladies, gentlemen, members of the public.

It is a matter of great regret and sadness to inform you that commit:

        Replace the linear search in find_pc_sect_line with a binary search.
        4ee89e903de920496a69c01df70db13a70a2a0be

might have made GDB unwell.  Since I am just your Butler BuildBot,
I kindly ask that a human superior officer double-check this.

Please note that if you are reading this message on gdb-patches, there might
be other builders broken.

You can find more details about the unfortunate breakage in the next messages.

Cheers,

Your GDB BuildBot.
    
From gdb-patches-return-146050-listarch-gdb-patches=sources.redhat.com@sourceware.org Tue Mar 20 15:11:45 2018
Return-Path: <gdb-patches-return-146050-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb-patches@sources.redhat.com
Received: (qmail 117680 invoked by alias); 20 Mar 2018 15:11:44 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
Delivered-To: mailing list gdb-patches@sourceware.org
Received: (qmail 117670 invoked by uid 89); 20 Mar 2018 15:11:44 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=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; Tue, 20 Mar 2018 15:11:43 +0000
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3])	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))	(No client certificate requested)	by mx1.redhat.com (Postfix) with ESMTPS id BE7B180AD238;	Tue, 20 Mar 2018 15:11:41 +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 16E2410B0F5B;	Tue, 20 Mar 2018 15:11:40 +0000 (UTC)
Subject: Re: [RFA v2] (x86) Fix watchpoint using hardware breakpoint for some distro
To: Xavier Roirand <roirand@adacore.com>, gdb-patches@sourceware.org
References: <1521209212-11264-1-git-send-email-roirand@adacore.com> <b8442988-85e3-dc87-0e4c-732395b8db93@redhat.com> <9c7c8586-2940-bea9-d3fb-a13b0d38a32e@adacore.com>
Cc: brobecker@adacore.com
From: Pedro Alves <palves@redhat.com>
Message-ID: <c0d80d21-9f0e-c6b0-caaf-7b6246e83807@redhat.com>
Date: Tue, 20 Mar 2018 15:11: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: <9c7c8586-2940-bea9-d3fb-a13b0d38a32e@adacore.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-SW-Source: 2018-03/txt/msg00379.txt.bz2
Content-length: 1151

On 03/20/2018 02:28 PM, Xavier Roirand wrote:
> Hello Pedro,
>
> I've replied to your comments and attached a v2 patch.
>
> Le 3/19/18 à 3:28 PM, Pedro Alves a écrit :
>> A few things are missing here:
>>
>> #1 - kernel versions where this was observed.
>>
>
> CentOS: 2.6.18-419.el5
> Suse: 2.6.27.19-5-pae
>
>> #2 - If it's not equal to TRAP_HWBKPT, then what's it equal to?
>>       I assume zero?
>
> No, it's equal to 1.

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?

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?

>> Does the step-into-watchpoint case result in TRAP_TRACE, or does
>> that result in 0 too?  That affects the "continue" in the comment above.
>
> This results to a value of 1 too.

What do those kernels report for hardware _breakpoints_?  Is it 1 too?
Wondering whether we should make GDB_ARCH_IS_TRAP_HWBKPT return
true for 1 too...

Please provide a more complete picture.

Thanks,
Pedro Alves