From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17348 invoked by alias); 4 Sep 2014 17:51:41 -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 17337 invoked by uid 89); 4 Sep 2014 17:51:39 -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; Thu, 04 Sep 2014 17:51:38 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XPbC2-0003fA-R7 from Maciej_Rozycki@mentor.com ; Thu, 04 Sep 2014 10:51:35 -0700 Received: from localhost (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 4 Sep 2014 18:51:33 +0100 Date: Thu, 04 Sep 2014 17:51:00 -0000 From: "Maciej W. Rozycki" To: Doug Evans CC: , , Yao Qi Subject: Re: [PATCH] Remove some obfuscation from ${arch}_skip_prologue functions In-Reply-To: Message-ID: References: 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/msg00126.txt.bz2 On Wed, 3 Sep 2014, Doug Evans wrote: > Can I enlist any of the other arch maintainers to regression test this > there: lm32, mips, arm, nios2, tic6x, tilegx, avr, moxie, sh? Thanks for working on these clean-ups. I'll try to push this through testing; what makes me curious about is whether there's a hidden trap here for compressed ISAs (i.e. MIPS16 and microMIPS code) where the value of the PC is not the same as the memory address of the instruction being accessed (the LSB or the ISA bit in the PC is forcefully set to 1). Another matter may be various MIPS16 call thunks. I have a vague recollection of my previous encounters with this code, but it was so many years ago I may have troubles bringing back what it really was, unless I am able to track down some patches. One issue here is not every possible execution path is covered in regression testing, some of the issues in places like this only happen in situations that are difficult to transform into a proper GDB test case (and e.g. our MIPS16 thunk tests remain non-functional with stock GCC because of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53276). Maciej