From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2926 invoked by alias); 22 Feb 2008 11:17:46 -0000 Received: (qmail 2915 invoked by uid 22791); 22 Feb 2008 11:17:45 -0000 X-Spam-Check-By: sourceware.org Received: from wf-out-1314.google.com (HELO wf-out-1314.google.com) (209.85.200.170) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 22 Feb 2008 11:17:25 +0000 Received: by wf-out-1314.google.com with SMTP id 29so237903wff.24 for ; Fri, 22 Feb 2008 03:17:23 -0800 (PST) Received: by 10.142.174.8 with SMTP id w8mr8596436wfe.5.1203679043312; Fri, 22 Feb 2008 03:17:23 -0800 (PST) Received: by 10.142.178.16 with HTTP; Fri, 22 Feb 2008 03:17:23 -0800 (PST) Message-ID: <8f2776cb0802220317q4fe3c813je07e8396920d2147@mail.gmail.com> Date: Fri, 22 Feb 2008 16:38:00 -0000 From: "Jim Blandy" To: "Nigel Stephens" Subject: Re: MIPS: Handle manual calls of MIPS16 functions with a call stub Cc: "Maciej W. Rozycki" , "Daniel Jacobowitz" , gdb-patches@sourceware.org, "Maciej W. Rozycki" In-Reply-To: <47B988D5.3060605@mips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080204163929.GA6642@caradoc.them.org> <8f2776cb0802081007v3978bbfbs4c91835ddd8c3885@mail.gmail.com> <8f2776cb0802131254p7fd04ba5lf908414940b7f622@mail.gmail.com> <47B988D5.3060605@mips.com> X-Google-Sender-Auth: 8fea40b38bb977fe X-IsSubscribed: yes 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: 2008-02/txt/msg00357.txt.bz2 On Mon, Feb 18, 2008 at 5:32 AM, Nigel Stephens wrote: > Maciej W. Rozycki wrote: > > On Wed, 13 Feb 2008, Jim Blandy wrote: > >> It seems that we all agree on the following: > >> > >> - It's contrary to the DWARF spec for producers to put arch-specific > >> information in the low bits of the addresses in the line number > >> table, function and block address ranges, and so on. Existing > >> toolchains that do this are buggy, but that's life. > > Hmm. The ELF symbol table has an "out of band" mechanism to distinguish > symbols which refer to different architectural encodings, using the > architecture-specific bits in the st_info field. But how would you > represent that in DWARF's object file encoding, noting that the > "MIPS16-ness" of an undefined symbol is not known at compile time, only > at final link time. > > And this is not just a way of sneaking architecture-specific > "information" through the object file: it is a fundamental aspect of the > MIPS architecture. From the running software's point of view bit 0 of > the PC must be set to execute MIPS16 instructions (e.g. when performing > an indirect jump or function call) and it will always be viewed as set > when made visible to software (e.g. in the return address register after > a function call, or saved on the stack, or in the exception program > counter). Bit 0 must therefore be set in any data which points to a > MIPS16 instruction. If you're going to conclude that DWARF DW_AT_low_pc and DW_AT_high_pc attributes ought to have bit zero set when they show the extent of MIPS16 code, I don't think that's right. After all, if I want to disassemble such an instruction, which address do I start reading bytes from? I must clear bit zero. Does DWARF information refer to undefined symbols? Doesn't the compiler know the mode associated with every symbol it refers to in DWARF? Couldn't relocs against DWARF data citing MIPS16 symbols subtract off bit 0 in the addend? GDB actually does have mechanisms (which Maciej mentions) for setting and masking off bit zero when writing and reading the PC. It seems to me GDB could look up the linker symbol associated with an address to find the appropriate mode.