Hi, any reason why a global alias is always emitted as a variable (as opposed to being a variable or a function depending on the aliasee)?
This has been the case since it was introduced in a8a74ece085c97df11d
@cachemeifyoucan do you know?
Thanks.
I don’t know the exact reason. I guess it just works well enough that no one comes around to improve that. Can you elaborate what problem are you facing with current implementation?
Feel free to improve but it would be good to have some solid examples for how the tools are using the function/data field. I don’t see this information too useful for alias (and machO doesn’t really have an alias, only a hacked version so I don’t know too much about the requirement for alias for other platforms).
Can you elaborate what problem are you facing with current implementation?
No particular problem. In certain stages in the linker, we need to know if the symbol is a function or not, and I can no longer trust the permissions flag (e.g. LTO_SYMBOL_PERMISSIONS_CODE implies it’s a function, but not for alias symbols). Since there’s no way to query the aliasee, I’m forced to assume that an alias symbol might be a function symbol. It’s not a big deal for now.
I see. Also I wonder how much you can trust this information from LLVM IR. I think it is legal from the ELF’s point view to have an alias to an undefined symbol and an object linker probably won’t care if the alias was intended for code or data and just resolve to whatever it finds. If you ask me, I will say only the linker should know after resolving the symbols if an alias is code or data.