patch for problem when mips16 hard float is linked as c++

[Richard Sandiford]

reed kotler <rkotler at mips.com> writes:
> On 02/12/2014 10:59 AM, Rafael Espíndola wrote:
>> On 12 February 2014 13:03, reed kotler <rkotler at mips.com> wrote:
>>> This patch has been rewritten to not use output raw text in MipsAsmPrinter
>>> and so is being sent out to the list
>>> before actual commit to make sure there are no further objections.
>> Thanks!
>>
>>> This patch has two main functions:
>>>
>>> 1) Fix a specific bug when certain conversion functions are called in a
>>> program compiled as mips16 with hard float and
>>> the program is linked as c++. There are two libraries that are reversed in
>>> the link order with gcc/g++ and clang/clang++ for
>>> mips16 in this case and the proper stubs will then not be called. These
>>> stubs are normally handled in the Mips16HardFloat pass
>>> but in this case we don't know at that time that we need to generate the
>>> stubs. This must all be handled later in code generation
>>> and we have moved this functionality to MipsAsmPrinter. When linked as C
>>> (gcc or clang) the proper stubs are linked in from libc.
>> This is strange, but as long as it is local to the Mips backend that
>> is probably fine. Can you share a bit more what the issue is? What
>> stub that needs to be generated but currently is not? When can you
>> find out that it is needed?
> Richard Sandiford  who is on this list now (and is the supreme gcc Mips 
> expert) can explain this latest wrinkle more fully.

I might have misunderstood, but it sounded like Rafael's question was more:
why is __floatdidf a special case?  And the answer is that it isn't really.
At least it isn't in GCC.  __floatdidf has the normal interface for a function
with its prototype and GCC handles it like calls to any other function.
I haven't looked at the LLVM code to see why LLVM needs to treat it as
a special case.

The link order difference that Reed mentions is just that libgcc_s.so
gets linked before libgcc.a for g++ but not for gcc, so an object linked
by g++ will resolve __floatdidf dynamically while an object linked by gcc
will resolve it statically.  If libgcc.a is compiled as MIPS16 then the
linker can resolve the __floatdidf call directly to the MIPS16 implementation,
so a missing stub wouldn't be noticed.

Thanks,
Richard