From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2980 invoked by alias); 10 Sep 2014 11:51: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 2966 invoked by uid 89); 10 Sep 2014 11:51:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 10 Sep 2014 11:51:08 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-05.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XRgQS-0005Vl-BK from Maciej_Rozycki@mentor.com ; Wed, 10 Sep 2014 04:51:04 -0700 Received: from localhost (137.202.0.76) by SVR-IES-FEM-05.mgc.mentorg.com (137.202.0.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 10 Sep 2014 12:51:02 +0100 Date: Wed, 10 Sep 2014 11:51:00 -0000 From: "Maciej W. Rozycki" To: Matthew Fortune CC: "gdb-patches@sourceware.org" , Joel Brobecker , Richard Sandiford Subject: RE: [committed] MIPS: Don't infer IRIX OS ABI from generic section names In-Reply-To: <6D39441BF12EF246A7ABCE6654B0235320F07EC6@LEMAIL01.le.imgtec.org> Message-ID: References: <6D39441BF12EF246A7ABCE6654B0235320F07EC6@LEMAIL01.le.imgtec.org> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2014-09/txt/msg00290.txt.bz2 On Wed, 10 Sep 2014, Matthew Fortune wrote: > > The problem here is we've got assembly source that does not have the > > usual ABI tag GDB normally infers the OS ABI from. > > Could you explain what 'usual ABI tag' refers to in this context? > I have a feeling there's another layer of ABI annotation that I > haven't seen yet. The thing that you get from glibc's csu/abi-note.S. > > I have verified this change to work correctly in mips-linux-gnu > > regression testing and committed now. > > Thanks for tracking this down it must have been quite time consuming. Not quite so, the hard part was realising that `vCont;s...' is not supposed to happen for a software-stepping target, the rest was easy. Actually it shows a deficiency in the way GDB works, that I believe has already been discussed, in that the switch between software and hardware stepping shouldn't really be arbitrary as it is now. Instead it should be the stub or the native backend that should report to the core of GDB whether hardware stepping is supported. Also right now the MIPS backend of `gdbserver' seems to know that hardware stepping is not supported, but it only uses that knowledge in some contexts and issues this `ptrace(PTRACE_SINGLESTEP, ...)' request anyway. > I'll try to sort out running some GDB tests for any further ABI > related work. I certainly wouldn't have guessed that .MIPS.abiflags > would break GDB. Well, the thing is in a sense it didn't break GDB, just revealed existing breakage, a place to be careful about and the lack of coverage at least in my testing. So I think it was good after all. Maciej