I have some stub functions that are essentially static, but they cannot be removed. What linkage type should I use in that case. Internal linkage appears to get the functions discarded if they are not referenced under certain optimizations. This is part of the gcc mips16 hack for floating point. For example, a function like floor from the math library will be called with an external reference to function floor. At that time, the compiler does not know whether floor was compiled as mips16 or mips32. It generates the call to floor as if it is a mips16 compiled function. It also generates a stub that the linker can use if during link time it is discovered that "floor" is a mips32 function. The stubs, which are mips32 code, will move the first argument register into a floating point register, call floor, and upon return will move the integer return value into a floating point register. If I designate this function as having internal linkage, then in some cases, the optimizer will throw it away. In that case, at link time it will call floor, and if floor is compiled as mips32, this will break a mips16 compiled program. The linker does not know there is an issue because only functions with certain kinds of signatures need a helper function for the call.
Maybe there is some attribute I can add this will not allow the function to be discarded. On 07/24/2013 03:45 PM, reed kotler wrote:> I have some stub functions that are essentially static, but they cannot > be removed. > > What linkage type should I use in that case. Internal linkage appears to > get the functions discarded if they are not referenced under certain > optimizations. > > This is part of the gcc mips16 hack for floating point. > > For example, a function like floor from the math library will be called > with an external reference to function floor. > > At that time, the compiler does not know whether floor was compiled as > mips16 or mips32. > > It generates the call to floor as if it is a mips16 compiled function. > > It also generates a stub that the linker can use if during link time it > is discovered that "floor" is a mips32 function. > > The stubs, which are mips32 code, will move the first argument register > into a floating point register, call floor, and upon return will move > the integer return value into a floating point register. > > If I designate this function as having internal linkage, then in some > cases, the optimizer will throw it away. > > In that case, at link time it will call floor, and if floor is compiled > as mips32, this will break a mips16 compiled program. > > The linker does not know there is an issue because only functions with > certain kinds of signatures need a helper function for the call.
Seems like -femit-all-decls partially works around this. But I would still like to solve the real problem of creating a function which is local/static but which cannot be thrown away by the optimizer if not referenced. On 07/24/2013 04:07 PM, Reed Kotler wrote:> Maybe there is some attribute I can add this will not allow the function > to be discarded. > > On 07/24/2013 03:45 PM, reed kotler wrote: >> I have some stub functions that are essentially static, but they cannot >> be removed. >> >> What linkage type should I use in that case. Internal linkage appears to >> get the functions discarded if they are not referenced under certain >> optimizations. >> >> This is part of the gcc mips16 hack for floating point. >> >> For example, a function like floor from the math library will be called >> with an external reference to function floor. >> >> At that time, the compiler does not know whether floor was compiled as >> mips16 or mips32. >> >> It generates the call to floor as if it is a mips16 compiled function. >> >> It also generates a stub that the linker can use if during link time it >> is discovered that "floor" is a mips32 function. >> >> The stubs, which are mips32 code, will move the first argument register >> into a floating point register, call floor, and upon return will move >> the integer return value into a floating point register. >> >> If I designate this function as having internal linkage, then in some >> cases, the optimizer will throw it away. >> >> In that case, at link time it will call floor, and if floor is compiled >> as mips32, this will break a mips16 compiled program. >> >> The linker does not know there is an issue because only functions with >> certain kinds of signatures need a helper function for the call.
On 07/24/2013 03:45 PM, reed kotler wrote:> I have some stub functions that are essentially static, but they cannot > be removed. > > What linkage type should I use in that case. Internal linkage appears to > get the functions discarded if they are not referenced under certain > optimizations. > > This is part of the gcc mips16 hack for floating point. > > For example, a function like floor from the math library will be called > with an external reference to function floor. > > At that time, the compiler does not know whether floor was compiled as > mips16 or mips32. >This description below is not completely correct. But the issue remains nevertheless that some of the static function stubs are being optimized below. I have filed a bug against myself to finally document this mips16/32 floating point interoperability scheme. Even after implementing it, I forget parts of how it works if I have not worked on it for a while.> It generates the call to floor as if it is a mips16 compiled function. > > It also generates a stub that the linker can use if during link time it > is discovered that "floor" is a mips32 function. > > The stubs, which are mips32 code, will move the first argument register > into a floating point register, call floor, and upon return will move > the integer return value into a floating point register. > > If I designate this function as having internal linkage, then in some > cases, the optimizer will throw it away. > > In that case, at link time it will call floor, and if floor is compiled > as mips32, this will break a mips16 compiled program. > > The linker does not know there is an issue because only functions with > certain kinds of signatures need a helper function for the call.