From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22449 invoked by alias); 1 Feb 2008 10:27:22 -0000 Received: (qmail 22441 invoked by uid 22791); 1 Feb 2008 10:27:21 -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; Fri, 01 Feb 2008 10:27:04 +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 1JKt6q-00028q-00; Fri, 01 Feb 2008 10:27:00 +0000 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1JKt6k-0002P7-00; Fri, 01 Feb 2008 10:26:54 +0000 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1JKt6k-00043f-3k; Fri, 01 Feb 2008 10:26:54 +0000 Date: Fri, 01 Feb 2008 10:27: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: <20080131220315.GC5085@caradoc.them.org> 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/msg00006.txt.bz2 On Thu, 31 Jan 2008, Daniel Jacobowitz wrote: > > The bit in the start address is set in the DWARF-2 record by BFD at the > > link time based on the STO_MIPS16 annotation of the symbol at the same > > address in the ELF symbol table. If the start address is the same as the > > regular entry point of the function, which is the case when no call stub > > has been generated for the function in question, then the DWARF-2 record > > gets updated accordingly and the bit is correctly set. However, when the > > call stub indeed is there, the function's entry point is at a different > > location, and the stub's entry point point is standard MIPS code and > > therefore bearing no STO_MIPS16 annotation. In this case the bit in the > > DWARF-2 record remains clear. > > Does this mean the DWARF block describes the MIPS16 parts, but the > function's minimal symbol points to the call stub, which is The other way round -- the minimal symbol points to the actual entry point, but the stub precedes it and is included in the DWARF-2 block together with the MIPS16 function body. Here's an example that triggers a failure in the test suite (generated from gdb.base/call-ar-st.c by GCC 4.2.2): .text .align 2 .globl print_ten_doubles .LFB20: .loc 1 664 0 # Stub function for print_ten_doubles (double, double) .set nomips16 .section .mips16.fn.print_ten_doubles,"ax",@progbits .align 2 .ent __fn_stub_print_ten_doubles __fn_stub_print_ten_doubles: .set noreorder mfc1 $4,$f13 mfc1 $5,$f12 mfc1 $6,$f15 mfc1 $7,$f14 .set noat la $1,print_ten_doubles jr $1 .set at nop .set reorder .end __fn_stub_print_ten_doubles .text .set mips16 .ent print_ten_doubles print_ten_doubles: .frame $17,8,$31 # vars= 0, regs= 2/0, args= 24, gp= 0 .mask 0x80020000,-4 .fmask 0x00000000,0 save 32,$17,$31 .LCFI36: addiu $17,$sp,24 .LCFI37: sw $5,12($17) sw $4,8($17) sw $7,20($17) sw $6,16($17) .loc 1 666 0 lw $4,.L134 lw $7,12($17) lw $6,8($17) lw $3,20($17) lw $2,16($17) sw $3,20($sp) sw $2,16($sp) jal printf .loc 1 667 0 lw $4,.L134 lw $7,28($17) lw $6,24($17) lw $3,36($17) lw $2,32($17) sw $3,20($sp) sw $2,16($sp) jal printf .loc 1 668 0 lw $4,.L134 lw $7,44($17) lw $6,40($17) lw $3,52($17) lw $2,48($17) sw $3,20($sp) sw $2,16($sp) jal printf .loc 1 669 0 lw $4,.L134 lw $7,60($17) lw $6,56($17) lw $3,68($17) lw $2,64($17) sw $3,20($sp) sw $2,16($sp) jal printf .loc 1 670 0 lw $4,.L134 lw $7,76($17) lw $6,72($17) lw $3,84($17) lw $2,80($17) sw $3,20($sp) sw $2,16($sp) jal printf .loc 1 671 0 move $sp,$17 restore 8,$17,$31 j $31 .align 2 .L134: .word .LC75 .end print_ten_doubles .LFE20: .size print_ten_doubles, .-print_ten_doubles The .LFB20 and .LFE20 labels are used as the boundaries of the function in the DWARF-2 block. > 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... Maciej