[lldb-dev] Proposal: Using LLD in tests

Thu Apr 19 10:44:31 PDT 2018

We already don't really have any.

All of the makefiles that build the inferiors use a gcc style command line
syntax, and the way we made that work on Windows is to use clang for the
compiler.  So MSVC is already out of the equation.

There may be one or two instances where we check in a PDB file, but that
doesn't really scale.

I've been working a lot on the PDB support in LLVM and we have some good
coverage there that our PDBs are "as good as" Microsoft PDBs, and in the
future we have plans to have a debug info test suite that tests
LLD-generated PDBs with Microsoft debuggers.  If we have coverage of that,
I think that should be sufficient and maybe not worth complicating the LLDB
test suite matrix over trying to test debugging with MSVC generated PDBs.

On Thu, Apr 19, 2018 at 10:19 AM Leonard Mosescu via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

>  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
>>
>
> _______________________________________________
> 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/2ed6ba6c/attachment.html>