From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14028 invoked by alias); 4 Feb 2008 16:14:16 -0000 Received: (qmail 14010 invoked by uid 22791); 4 Feb 2008 16:14:15 -0000 X-Spam-Check-By: sourceware.org Received: from dmz.mips-uk.com (HELO dmz.mips-uk.com) (194.74.144.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 04 Feb 2008 16:13:57 +0000 Received: from internal-mx1 ([192.168.192.240] helo=ukservices1.mips.com) by dmz.mips-uk.com with esmtp (Exim 3.35 #1 (Debian)) id 1JM3xB-00055H-00; Mon, 04 Feb 2008 16:13:53 +0000 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1JM3x7-0007gH-00; Mon, 04 Feb 2008 16:13:49 +0000 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1JM3x6-0000fZ-Oa; Mon, 04 Feb 2008 16:13:48 +0000 Date: Mon, 04 Feb 2008 16:14:00 -0000 From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: gdb-patches@sourceware.org, "Maciej W. Rozycki" Subject: Re: MIPS: Handle manual calls of MIPS16 functions with a call stub In-Reply-To: Message-ID: References: <20080131220315.GC5085@caradoc.them.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: macro@mips.com 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/msg00073.txt.bz2 On Fri, 1 Feb 2008, Maciej W. Rozycki wrote: > > elsewhere)? Maybe mips_write_pc should use mips_pc_is_mips16; that's > > how Thumb works, by always consulting the minimal symbol table to find > > out whether an address should be called as MIPS16 or MIPS32. > > The ABI is different, so it is not enough to set the PC correctly -- more > about it in the patch that is going through my regression testing at the > moment. Though perhaps the other places could use mips_pc_is_mips16() > too. On the other hand I feel setting the block's start address correctly > is the right way to make the handling consistent throughout -- by using > mips_pc_is_mips16() here and there some places may be omitted by accident. > Hmm... I have tried your suggestion of using mips_pc_is_mips16() in mips_write_pc(), but it only removes some of the regressions. I think your proposal could work if the LSB of MIPS16 addresses was explicitly cleared throughout processing within GDB as all the DWARF-2 records referring to such addresses are currently meant to have it set. This is obviously because the R_MIPS_32 relocation is used for them as well as where an address of a function is taken for the purpose of making a call, so all these places are treated the same by the linker and GDB is prepared to it. Obviously the problem in the first place is in the way the stub is annotated with debugging information. Moving it outside the block describing the associated actual function breaks backtracing and single-stepping quite badly if I recall correctly. The DWARF-3 spec actually provides for such special code fragments by the means of the DW_AT_trampoline attribute, but GCC does not really have any infrastruture for handling it yet, except from recognising the name of the attribute. Until that is adopted I think we should have means to handle stubs regardless and even once GCC has been updated I think older binaries should be kept supported by reasonable means. Please note that for MIPS16 we have return stubs too. ;-) Maciej