From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46740 invoked by alias); 28 Mar 2018 19:33:39 -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 46313 invoked by uid 89); 28 Mar 2018 19:33:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=involves, sony, Andrew, Sony X-HELO: 9pmail.ess.barracuda.com Received: from 9pmail.ess.barracuda.com (HELO 9pmail.ess.barracuda.com) (64.235.154.211) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Mar 2018 19:33:37 +0000 Received: from MIPSMAIL01.mipstec.com (mailrelay.mips.com [12.201.5.28]) by mx1411.ess.rzc.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Wed, 28 Mar 2018 19:32:06 +0000 Received: from [10.20.78.31] (10.20.78.31) by mips01.mipstec.com (10.20.43.31) with Microsoft SMTP Server id 14.3.361.1; Wed, 28 Mar 2018 12:27:43 -0700 Date: Wed, 28 Mar 2018 19:33:00 -0000 From: "Maciej W. Rozycki" To: Simon Marchi CC: Tom Tromey , Subject: Re: [RFA 1/2] Make line tables independent of progspace In-Reply-To: Message-ID: References: <20180321171809.13115-1-tom@tromey.com> <20180321171809.13115-2-tom@tromey.com> <87zi2uw3uc.fsf@tromey.com> <87vadiw24a.fsf@tromey.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-BESS-ID: 1522265426-452059-3813-6252-8 X-BESS-VER: 2018.4.1-r1803281637 X-BESS-Apparent-Source-IP: 12.201.5.28 X-BESS-Outbound-Spam-Score: 0.50 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.191489 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound 0.50 BSF_RULE_7582B META: Custom Rule 7582B X-BESS-Outbound-Spam-Status: SCORE=0.50 using account:ESS59374 scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND, BSF_RULE_7582B X-BESS-BRTS-Status:1 X-SW-Source: 2018-03/txt/msg00590.txt.bz2 On Tue, 27 Mar 2018, Simon Marchi wrote: > Anyway, I just have some small comments here, otherwise the patch LGTM. Maybe > it would be a good idea to get the opinion of Maciej (in CC) for the > addr_bits_remove part? It's not clear to me offhand what the impact on processing that involves `addr_bits_remove' the change proposed will have. So what specifically would you like me to comment on here? As to the MIPS handler it seems ill-conceived to me. On 64-bit MIPS hardware 32-bit addresses are architecturally sign-extended, so assuming that the comment in `mips_addr_bits_remove' is correct any workaround for inconsistent handling should have been made the other way round, that is by sign-extending rather than zero-extending addresses. This hack was introduced with: commit 96431497ff2c780978d95f5fda7148ba732dcae0 Author: Mark Alexander Date: Wed Nov 27 03:40:02 1996 +0000 and then the default for whether to mask was changed to off with: commit 4014092b582281f6db1c43f618d3722561fb01e6 Author: Andrew Cagney Date: Tue Jul 11 09:25:22 2000 +0000 I'm tempted to remove the hack altogether as nowadays we should be getting the sign-extension right for 32-bit addresses everywhere. I know of a single case of hardware, the Sony R5900 processor (used in the PS2 video game console), which is 64-bit but has addressing limited to 32 bits and, contrary to what the MIPS architecture requires, does not sign-extend the PC correctly. This is only observable with the link register (typically $ra) and the JAL/JALR/BGEZAL/BGEZALL/BLTZAL/BLTZALL instructions that copy the value of the PC there. And then only in bare metal debugging, as bit #31 is only set for kernel mode addresses. I don't think any bare metal debugging facility is available for that processor though, and if one turns up, then we can think how to deal with that. FWIW, Maciej