[lldb-dev] Proposal: Using LLD in tests

Leonard Mosescu via lldb-dev lldb-dev at lists.llvm.org
Thu Apr 19 10:19:23 PDT 2018


>
>  the PDB tests under lit/SymbolFile/PDB need a linker to produce the program
> database


With this proposal, would we preserve any coverage for MSVC produced debug
information?

On Thu, Apr 19, 2018 at 9:47 AM, Greg Clayton via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

>
>
> > On Apr 19, 2018, at 9:39 AM, Pavel Labath <labath at google.com> wrote:
> >
> > 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.
>
> The problem is the linker must produce a debug map in the symbol table
> that contains the addresses of all linked items. So using LLD won't work
> unless that is fully supported as LLDB won't be able to like the debug info
> on the fly, nor will dsymutil have a debug map to use in order to make a
> dSYM file.
>
> >
> > 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.
>
> What I was trying to say is this is fine if we always compile/link as an
> ELF file with some triple that uses ELF for these tests. They just probably
> shouldn't be mach-o.
>
> Greg
>
> >
> >
> > 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
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180419/9b0d2d54/attachment.html>


More information about the lldb-dev mailing list