[lldb-dev] Proposal: Using LLD in tests

[Pavel Labath via lldb-dev]

Yes, I considered the lld+Mach-O situation. I understand that it does not
work very well, but I don't know what exactly that means.

However, I am not sure that we even need a linker for Mach-O. As I
understand it, in a darwin world, the linker does not even touch the debug
info, and lldb is already capable of reading the debug info from .o files.
So at least for non dsym-case it seems to me we should be good. It may be
possible we need a linker for the dSYM (i don't know exactly how that
works), in which case we may just not be able to test dsym this way, but
even that will be better than what we have now.

PS: I am not proposing to do anything to the existing dotest tests (they
need access to a running process anyway, so playing with the linker will
not help). I am just trying to make new debug-info specific tests
universally available.


On Thu, 19 Apr 2018 at 17:24, Greg Clayton <clayborg at gmail.com> wrote:

> The last I knew LLD doesn't work on mach-o very well, so be sure to not
require LLD for linking any Darwin executables.

> > On Apr 19, 2018, at 6:42 AM, Pavel Labath via lldb-dev <
lldb-dev at lists.llvm.org> wrote:
> >
> > Hello all,
> >
> > currently we have a couple of tests, in-tree or under review, which are
> > very close to being host-independent. The only part they are missing is
the
> > ability to link a intermediate object file:
> > - the ppc64 test in https://reviews.llvm.org/D44437 needs a linker to
> > resolve relocations in the debug info (*)
> > - the PDB tests under lit/SymbolFile/PDB need a linker to produce the
> > program database.
> >
> > I think it would be great if everyone were able to run these tests and
> > verify they don't regress them before they actually push a patch.
> >
> > Apart from that, I have started looking at writing some non-execution
debug
> > info (**) tests as a part of adding DWARF v5 accelerator table support
to
> > lldb (both to test the new implementation, and to make sure I don't
regress
> > existing ones). Ideally I'd like to make sure that everyone is able to
run
> > them, regardless of their primary (or only) development platform. For
this,
> > I also need a linker capable of running everywhere (*)
> >
> > To achieve these goals, I'd like to propose that we add LLD as a
(optional,
> > but strongly recommended) dependency for running tests and start using
it
> > in the tests I mention. Doing this would optional in the sense that the
> > tests would be marked "REQUIRED: lld", and simply skipped if lld is not
> > available (so the tests would still be green). I say "strongly
recommended"
> > because not having lld checked out should not be an excuse for breaking
the
> > test, and the patch author should pro-actively revert a patch which
breaks
> > such tests and investigate.
> >
> > I hope this proposal is not too controversial. LLD is already required
on
> > windows to run dotest tests. Also, all monorepo users likely have it
> > already, or it is very easy for them to enable it. For non-monorepo
users
> > it should be a matter of checking out one extra repository. Please Let
me
> > know what you think.
> >
> > pavel
> >
> > (*) our ELF parser has very limited support for applying debug info
> > relocations -- it only works for x86, and only a couple of relocations
are
> > currently implemented. It would be possible to remove the linker
dependency
> > by implementing these (essentially, doing the link ourselves -- this is
> > what llvm does), but given the large number of architectures and
relocation
> > types, combined with the long term goal of reusing the llvm's ELF
parser,
> > this does not seem like a worthwhile goal. Also, it does not help the
> > windows situation, as in the PDB model it's the linker who produces the
> > pdb's.
> >
> > (**) I'll write a separate email about this, but what I'm essentially
> > thinking of is producing a stand-alone module (either from .yaml, .s,
.ll,
> > or .c), hitting it with various FindXXX methods, and dumping the
results.
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev