Re: MIPS: Handle manual calls of MIPS16 functions with a call stub

["Maciej W. Rozycki" <macro@mips.com>]

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