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

Maciej W. Rozycki
2008-02-01T10:27:22Z

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