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

[Daniel Jacobowitz <drow at false dot org>]

On Fri, Feb 01, 2008 at 10:26:54AM +0000, Maciej W. Rozycki wrote:
> 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):

Then why aren't we calling the instruction at the start of the block,
i.e. the stub?  In which case not using the MIPS16 convention is
correct.  I don't see why you'd want to call
__fn_stub_print_ten_doubles as a MIPS16 function.

-- 
Daniel Jacobowitz
CodeSourcery