From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10800 invoked by alias); 31 Dec 2003 16:53:17 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 10793 invoked from network); 31 Dec 2003 16:53:16 -0000 Received: from unknown (HELO sadr.equallogic.com) (66.155.203.134) by sources.redhat.com with SMTP; 31 Dec 2003 16:53:16 -0000 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hBVGrGf9020033 for ; Wed, 31 Dec 2003 11:53:16 -0500 Received: from deneb.dev.equallogic.com (deneb [172.16.1.99]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hBVGrGiu020028; Wed, 31 Dec 2003 11:53:16 -0500 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id hBVGrFS17800; Wed, 31 Dec 2003 11:53:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16370.65275.609000.91914@gargle.gargle.HOWL> Date: Wed, 31 Dec 2003 16:53:00 -0000 From: Paul Koning To: drow@mvista.com Cc: gdb@sources.redhat.com Subject: Re: Looking for a gdb function to handle alias addresses References: <16369.64013.161868.574183@gargle.gargle.HOWL> <20031230230043.GA17557@nevyn.them.org> <16370.60074.841000.648191@gargle.gargle.HOWL> <20031231163751.GA18231@nevyn.them.org> X-SW-Source: 2003-12/txt/msg00297.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: >> If the latter, is another gdbarch function hook the right way? Daniel> Maybe. What you're describing is very system-specific, Daniel> rather than architecture-specific - I realize that the basic Daniel> K0/K1 is a standard MIPS feature, but the details of what Daniel> regions alias will definitely vary based on more than the Daniel> gdbarch. So perhaps it should be directly user-configurable Daniel> instead. It certainly is system-specific. The K0/K1 and also the corresponding 64-bit aliases are MIPS standard. But in my case, I also wanted an alias from a 64-bit unmapped address to a canonical address that's mapped (through the user address space, no less) and that's a programmable mapping that's specific to our target. I wasn't thinking user-configurable because the mapping I have is fixed for the platform, so I'd rather program it in. My dump analyzer already knows a whole lot of hairy details about that target anyway... :-) Also, a rule of the form "walk through the VM region descriptors for a region that maps to the physical address, and take the inverse" is hard to express in the UI. >From what I've heard so far I'm inclined to make this a private hook, without a lot of effort spent to make it nice & generic because it's not likely to be generally useful/applicable. Thanks Daniel.... any other opinions/comments would also be welcome. paul