jakehehrlich added a comment. In D60974#1474751 <https://reviews.llvm.org/D60974#1474751>, @plotfi wrote:
> There are a few that I have in mind. > > 1. -emit-ifso could be added to a build to produce .so files as part of a > device SDK (where we don't want to ship the runnable bits in the SDK, we ship > those on the device updates). This would require creating a linker for these files. Is this what you intend to do? > 2. -emit-ifso could be added to whatever the existing set of build flags are > to be run as a pre-build step to produce tapi-like .so files that break up > build dependencies. How would this work? To be clear, this would happen at the same time that .o files are produced correct? The build graph would basically look the same but your new linking step would replace the original link step and there would be a pendent node for the original link step. This would not break up the build graph much at all save for the fact that we might imagine that this new link step would be much faster. > 3. -emit-ifso -fvisibility=hidden could added to the invocation to disallow > usage of non-public apis. Can you be more specific? This is already how the actual modules do this today so what is the advantage here. > The way we are thinking it would work is similar to the dwos and .o files > where you get one .ifso for each TU, then have a link-action that merges the > mangled names and produces the .so file. That requires a linker but one that only has to link dwarf which is designed to be linked using the dumbest possible semantics so that it can be format agnostic and not create undo complexity in the linker. The linker needed for this sort of thing would have to understand almost everything that a real full linker has to just to determine if a symbol is public or not. I think this might even require processing relocations. Beyond being public symbols have extra information that matters at both static and dynamic link time. This is mostly just point out how complicated this task is and not a complaint about the current output format. That could be improved but we have to be aware of the complexity of introducing yet a third type of linker and the issues with maintaining parity with the behavior of existing linker as well. In particular I think introducing a linker is an even bigger llvm-dev discussion that we need to have before we should proceed with this method. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60974/new/ https://reviews.llvm.org/D60974 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
