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

Daniel Jacobowitz
2008-02-01T14:19:04Z

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