From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22534 invoked by alias); 18 Feb 2010 19:20:10 -0000 Received: (qmail 22505 invoked by uid 22791); 18 Feb 2010 19:20:07 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.17.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Feb 2010 19:19:59 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id o1IJJvXl012487 for ; Thu, 18 Feb 2010 19:19:57 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o1IJJuWw1278030 for ; Thu, 18 Feb 2010 20:19:56 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o1IJJuYT023652 for ; Thu, 18 Feb 2010 20:19:56 +0100 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id o1IJJtow023642; Thu, 18 Feb 2010 20:19:55 +0100 Message-Id: <201002181919.o1IJJtow023642@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 18 Feb 2010 20:19:55 +0100 Subject: Re: MIPS dwarf2 location lists To: dan@codesourcery.com (Daniel Jacobowitz) Date: Thu, 18 Feb 2010 19:20:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20100218172404.GB9493@caradoc.them.org> from "Daniel Jacobowitz" at Feb 18, 2010 12:24:05 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2010-02/txt/msg00461.txt.bz2 Daniel Jacobowitz wrote: > On Thu, Feb 18, 2010 at 05:47:32PM +0100, Ulrich Weigand wrote: > > On Cell, the GDB addresses encode the SPU ID for addresses within > > SPU contexts attached to the process. In the target format (which > > is also used in object files, including DWARF addresses etc.), an > > address is a plain SPU local store address. > > > > When gdbarch_integer_to_address is called, we attach the SPU ID > > into the high word of the 64-bit CORE_ADDR; for example, an SPU > > local store address of 0x3f000 in SPU context #7 gets encoded > > into a CORE_ADDR value of 0x800000070003f000. > > > > gdbarch_integer_to_address is the right place to do this, because > > we want the transformation to also happen for addresses entered > > as literals on the command line, for example. > > As an aside, I've been thinking about this model. We have grown a lot > of support for multiple address spaces since this was implemented. > Is that something we can use instead of overloading CORE_ADDR bits? > It'd be a big project; I think values would need to carry an address > space around. Yes, this would be nice to fix. One problem is that we'd not just need multiple address spaces, but also multiple program spaces -- each SPU context has its own object file(s) loaded. And even in current GDB, we still have fundamentally just one program space per inferior; rooting out the current_program_space global will be a nontrivial effort. Values (at least lval_memory values) would certainly need to carry an address space. For values of pointer type, we'd also need the address space of the object pointed to -- this may be different from the one where the pointer itself resides. > My best idea is to separate addresses and offsets - as you've > suggested, and I think Mark suggested this week also - and define > offsets as sign extended. I'm not entirely confident that will work, > though, because when we get an offset we don't know if it's supposed > to wrap around or not. If you have a binary linked at zero (because > it's position-independent, say), and it's loaded at 0x90000000, then > is that a positive or negative offset? On a 32-bit platform, with > 64-bit CORE_ADDR, if you define that as a positive offset you'll break > MIPS. If you define it as a negative offset you'll break x86 and > SPU (it'll decrement the SPU number in the address). Obviously I'd > have to pick a different example for it to make sense on SPU, since > they have a tiny local store. Actually, I think this can be made to work. Basic rule needs to be that an offset is always computed as the difference between two addresses, where addresses have undergone the appropriate platform-specific treatment. So in your example, link address zero would be CORE_ADDR 0 on both i386 and mips (note that even zero would actually become something like 0x8000000700000000 on spu!), but the load address 0x90000000 would be CORE_ADDR 0x90000000 on i386 but 0xffffffff90000000 on mips. Subtracting the link address would thus result in the appropriate offset for the platform. Or, to look at it differently, if we compute the offset to move A to B as (B - A), adding that offset to A will always result in B again, as long as both the subtraction and the addition are performed on plain CORE_ADDR values. As long as addresses A and B are always computed like addresses on the platform need to be, we should be fine. (There is the theoretical case that if we apply the offset (B - A) to some address that is itself offset, like A + x, we could get wrong overflow. But this can really only occur if a single objfile is wrapped around the top of memory -- I don't think this is really possible.) > > As to build_section_addr_info_from_objfile, I'm wondering what problem the > > masking was supposed to address: > > > > sap->other[i].addr = (bfd_get_section_vma (objfile->obfd, sec) > > + objfile->section_offsets->offsets[i]) & mask; > > > > It looks like this happens if an object is loaded below its original load > > address (I guess this can happen if a prelinked object is loaded somewhere > > else), and thus the section_offsets need to be negative, which may not > > work as intended as CORE_ADDR is unsigned. It seems that whoever computes > > the section_offsets in this particular case ought to be able to compensate ... > > FWIW, the patch was here: > > http://sourceware.org/ml/gdb-patches/2009-11/msg00173.html If the offsets were computed as outlined above, it seems to me this should always work. It's not quite clear from the patch description where this is assumption is violated ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com