Description
Follow-up to #54959 with another failing case.
When constructing runtime.inlinedCall
entries, we fetch the inlined function FuncID from the FuncInfo.
When building in -linkshared
mode, if the inlined function is from the standard library (e.g., sync/atomic.(*Int64).Add
), then it is an "external" symbol and Loader.FuncInfo
will find no FuncInfo because we don't load an auxs for external symbols (that would likely happen here, though I don't think the ELF contains the auxs at all.
The result is that the inlinedCall
is left with the default FuncID (FuncID_normal
), even if that is incorrect.
Note that this is not a problem for the other FuncInfo users, notably the pcsp, pcfile, pcline, etc tables. Those ultimately end up in the moduledata
. There are multiple moduledata
s: one for libstd.so
and one for the main binary. Linking of libstd.so
has access to all the FuncInfo
s it needs to construct the moduledata
for libstd.so
. It is only a problem for inlinedCall
because we need cross-module data.
There are two ways I can see of addressing this:
-
Ensure
FuncInfo
availability for external symbols. Since the symbol aux data is not directly available inlibstd.so
, this could be done by reverse engineering it from the shared objectmoduledata
symbol (blegh), or (I believe) in addition to to thepackageshlib
pointing tolibstd.so
, the importcfg also includes thepackagefile
with the original package Go object file. We could reach into that file just for the symbol aux data. -
Eliminate the
FuncInfo
-based data frominlinedCall
. If we ensure that every inlined function has a_func
in the function table, then at runtime we could lookup the_func
from the inlined symbol name and get the metadata from there. For cross-module inlining, this means that the linker never needs to know the metadata at all.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status