George Rimar <grimar@accesssoftek.com> writes:
I am on PTO, so slow to respond.
Some items that are left:
* Debug fission
* Single file debug fission
* Range extension thunks
* All of freebsd links and works
* Very good performance when all that is in
Looks we have initial version of debug fusion implemented.
r289790, r289810 commits from yesterday did the rest of main job I believe.
I do not know what is "Single file debug fission" ? (quick googling gives nothing and I never heard about that before I think)
The idea is to design and implement a way to keep the .dwo data in the
same file as the .o. Having two files is nice for a cluster build, but
not for a local build with ccache.
Cheers,
Rafael
Rui Ueyama <ruiu@google.com> writes:
So, as a project, there is no anti-library policy in LLD. I think this is
the misunderstanding one side had. We already provide main-as-a-library
feature so that you can embed the linker to your program. We as a project
welcome other ideas to export linker features at a well-defined boundary.
For example, I think abstracting the file system access so that you can
hook file operations could be a well-defined, useful API for those who want
to do in-memory linking (I expressed that opinion already in this thread).
Just like LLVM, we won't guarantee API compatibility between releases, and
we are unlikely to be able to expose deep internals of the linker, but as
long as you think you found a reasonable coarse API boundary, there should
be nothing preventing you from bringing that to the table.
It really depends on what is meant by a library.
If we have to remove all calls to exit, all memory pools and all global
variables I am very opposed to it.
lld is an actual project with actual value for its users. I really don't
want to compromise its maintainability by turning every
for (auto &X : check(...))
into
auto XsOrErr = ...;
if (std::error_code EC = XsOrErr.getError())
return EC; // also update callers. Add more context to the return if
// you don't want to degrade the error message.
auto &Xs = *XsOrErr;
for (auto &X : Xs)
In the name of a theoretical user. Really, can we put this on hold
until the MachO linker has shown how to get its parts actually reused?
Cheers,
Rafael
Rui Ueyama <ruiu@google.com> writes:
> So, as a project, there is no anti-library policy in LLD. I think this is
> the misunderstanding one side had. We already provide main-as-a-library
> feature so that you can embed the linker to your program. We as a project
> welcome other ideas to export linker features at a well-defined boundary.
> For example, I think abstracting the file system access so that you can
> hook file operations could be a well-defined, useful API for those who
want
> to do in-memory linking (I expressed that opinion already in this
thread).
> Just like LLVM, we won't guarantee API compatibility between releases,
and
> we are unlikely to be able to expose deep internals of the linker, but as
> long as you think you found a reasonable coarse API boundary, there
should
> be nothing preventing you from bringing that to the table.
It really depends on what is meant by a library.
If we have to remove all calls to exit, all memory pools and all global
variables I am very opposed to it.
It would depend. If there was a *really* compelling use case it might be
worth it.
I think what you're saying is basically: the linker is currently much
simpler and easier to maintain due to the fatal errors on corrupted input,
globals for the "context", etc.
We need a compelling use case to give that up, and nothing sufficiently
compelling has been presented. And currently the focus is on feature parity
with existing linkers and systems, so naturally we aren't exploring tons of
new use cases unless our users come to us with requests.
In fact, I would say that as we've implemented the linker and as a
community of LLD developers learned more about linkers, many of the
theoretical use cases seem less realistic than before.
We're still doing some of the things that the LLD originally set out to do.
For example, LLD/ELF has grown color diagnostics and will dig through DWARF
to give source locations (it's like one or two function calls into the LLVM
libraries to do this, so there's nothing left to "factor out" from LLD/ELF
itself).
-- Sean Silva
Sean Silva <chisophugis@gmail.com> writes:
It would depend. If there was a *really* compelling use case it might be
worth it.
I think what you're saying is basically: the linker is currently much
simpler and easier to maintain due to the fatal errors on corrupted input,
globals for the "context", etc.
We need a compelling use case to give that up, and nothing sufficiently
compelling has been presented. And currently the focus is on feature parity
with existing linkers and systems, so naturally we aren't exploring tons of
new use cases unless our users come to us with requests.
Yes, the is good expansion of my position. To the best of my knowledge
the only two actual code "chunks" in lld that have correspondence in
llvm are the thread pool and the relocation application.
I think everyone agrees on the thread pool, it should be unified and one
day we should be able to use just the c++ standard library.
The relocation application is not clear and the lld one might not even
be in its final form, so it is too early to tell.
Cheers,
Rafael
Going above and beyond to avoid crashing for invalid use of the API is
nice, and results in fewer bug reports filed for the library that should be
filed for the upstream application.
However, it's not required for a robust library. The weaker guarantee of
adhering to the API causing no exit paths in the library, is easier to
adhere to, while still letting the upstream application developer create
software that does not crash in the library regardless of the user input.
Trying to go beyond this guarantee is the kind of thing that will make
development less pleasant for Rafael and co, and while nice, is not really
necessary.