[LLVMdev] Can we establish layering for the LLD libraries? Current state is a bit of a mess...

Chandler Carruth chandlerc at google.com
Mon Jan 19 18:33:06 PST 2015


I wanted to go through and map out the layering of LLD's libraries today
and found that it's essentially impossible. I think some serious cleanup is
needed here.

Let's start with the purely link-level dependencies encoded in the CMake
build:

Curently the Core library depends on the ReaderWriter/Native library, which
links against the ReaderWriter library, which links against the Core
library. This clearly cannot work. The same cycle exists with Core -> YAML
-> ReaderWrite -> Core.


The situation seems a bit worse for includes. If you start from
LinkingContext.h I think this becomes quite clear. This is ostensibly part
of the Core library, but it has methods that produce types from the
ReaderWriter library. Combined with the fact that ReaderWriter depends on
Core (not the other way around) and ReaderWriter/ELF subclasses
LinkingContext, I can't make heads or tails of what was intended here.


My vague guess is that Core should actually be two libraries. One that
doesn't depend on anything (other than Config) and provides the very "core"
types for LLD. And another, perhaps called "Linker" which is a much
higher-level library and provides useful APIs for actually doing linking,
depends on ReaderWriter and provides methods that manipulate it. I could
even see needing to spilt the target libraries in a similar manner.


But I don't know LLD's design well, I'm just trying to stitch the build
system back together in a reasonable way, so maybe I've missed things
completely. So help me out. I'd like to understand a reasonable DAG in
which to construct libraries for LLD. Having this should allow proper
layering, layering checks, and eventually building with C++ modules. All of
which seem essentially impossible today.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150119/bd88d1b0/attachment.html>


More information about the llvm-dev mailing list