[llvm-bugs] [Bug 49514] New: -t does not print dylibs loaded by -flat_namespace

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=49514

            Bug ID: 49514
           Summary: -t does not print dylibs loaded by -flat_namespace
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: MachO
          Assignee: unassignedbugs at nondot.org
          Reporter: nicolasweber at gmx.de
                CC: gkm at fb.com, jezreel at gmail.com,
                    llvm-bugs at lists.llvm.org, smeenai at fb.com

(Mostly note for future self (?))

We need tests that dylibs loaded from -flat_namespace are in -t output (at the
moment, they aren't), and that they are in --reproduce output (this is already
correct, I think).


This command can be used for local testing after running `check-lld`:

    out/gn/bin/ld64.lld -syslibroot  lld/test/MachO/Inputs/MacOSX.sdk
-flat_namespace out/gn/obj/lld/test/MachO/Output/flat-namespace.s.tmp/main.o
out/gn/obj/lld/test/MachO/Output/flat-namespace.s.tmp/baz.dylib -o
out/gn/obj/lld/test/MachO/Output/flat-namespace.s.tmp/out -t -flat_namespace
--reproduce=repro.tar


Interesting things to check:

+    // - normal .dylib on cmdline not printed twice
+    // - dylib from -flat_namespace in LC_LOAD_DYLIB not printed twice
+    // - reexport-library
+    // - LC_LOAD_WEAK_DYLIB
+    // - order of -t output (should be main baz bar foo)
+    // - --reproduce with these


I tried implementing this by putting

+  if (config->printEachFile)
+    message(toString(this));

in the two Dylib ctors and not printing dylibs in addFile() in Driver if
isa<DylibFile>(newFile).

However, that doesn't quite work: Since the Dylib ctors recursively load more
dylibs for flat_namespace, the cache in loadDylib() in DriverUtils.cpp is
updated too late (only after the whole recursion has completed), and we print
some dylibs more than once then.

It's probably not a great idea to recursively load dylibs in the DylibFile ctor
and we should do that after construction in a dedicated method. That'd mean
DylibFile would have to keep a list of pending dylib loads.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210310/1e768ef4/attachment-0001.html>