[PATCH] D22677: [ThinLTO/gold] Support for getting list of included objects from gold

[Xinliang David Li via llvm-commits]

On Fri, Jul 22, 2016 at 9:23 AM, Teresa Johnson <tejohnson at google.com>
wrote:

> tejohnson added a comment.
>
> In https://reviews.llvm.org/D22677#492930, @davidxl wrote:
>
> > For the functional case, I meant the tests in
> https://reviews.llvm.org/D22356 -- that with this patch we don't end up
> with unsats in second link.
>
>
> Right, for this patch to fix that case it needs gold v1.12, and there
> isn't a way to require a certain gold version on the bots.
>


I thought one of the issue is that the first link does not drop any, but
the second link drops it if the same command line is used.  If the first
link does not drop any, is v1.12 still needed?

David

>
>
> ================
> Comment at: test/tools/gold/X86/thinlto_emit_linked_objects.ll:18
> @@ +17,3 @@
> +; RUN:    %t.o \
> +; RUN:    --start-lib %t2.o --end-lib
> +
> ----------------
> davidxl wrote:
> > tejohnson wrote:
> > > davidxl wrote:
> > > > Perhaps add test case about real archive case as well.
> > > For a distributed build the build system needs to extract the
> constituent objects (otherwise the combined index paths will not point to
> an object file)
> > I think this feature is more about two step link (not about a particular
> distributed build system). It is possible that some other distributed build
> system uses archive, right?
> Using archives directly with a distributed build won't work - the combined
> index module paths need to point to an object file for the distributed
> backends to import from. The build system needs to extract the objects
> (e.g. into a temp dir) and pass those.
>
> Note that archives passed to a non-distributed build work fine because we
> load the modules from the offset within the archive passed to the plugin
> from gold and serve those to the importer.
>
> ================
> Comment at: test/tools/gold/X86/thinlto_emit_linked_objects.ll:21
> @@ +20,3 @@
> +; RUN: cat %t3 | FileCheck %s
> +; CHECK: thinlto_emit_linked_objects.ll.tmp.o
> +; CHECK: thinlto_emit_linked_objects.ll.tmp2.o
> ----------------
> davidxl wrote:
> > tejohnson wrote:
> > > davidxl wrote:
> > > > Can the name between bitcode file and final object files be made
> more related ?
> > > The ThinLink gold invocation doesn't know the name of the final object
> files. But note that if a prefix replace path is specified
> (thinlto-prefix-replace=oldprefix:newprefix plugin option), then the names
> emitted will have the matching prefix path replaced with the new one. This
> can be used to get the paths to the final object files into the file, as
> long as the final objects use the same names but a different path (true in
> bazel). Otherwise the build system would need to do post-processing of the
> list to map to the final object files it is going to create - known by the
> build system but not by gold here.
> > This request is more about test case readability. Suppose --start-lib
> and --end-lib pair includes two bit code files, but one of them is dropped
> in the first link. In the second step, we need to be able to tell which one
> maps to the kept one..
> Is the concern that it isn't obvious how %t.o and %t2.o map to lines in
> the CHECK? Note though that both are included in the link due to the gold
> version issue mentioned in the comments, so it should be pretty clear in
> this test case I think?
>
>
> https://reviews.llvm.org/D22677
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160722/90583ce0/attachment.html>