<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - -t does not print dylibs loaded by -flat_namespace"
href="https://bugs.llvm.org/show_bug.cgi?id=49514">49514</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>-t does not print dylibs loaded by -flat_namespace
</td>
</tr>
<tr>
<th>Product</th>
<td>lld
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>MachO
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>nicolasweber@gmx.de
</td>
</tr>
<tr>
<th>CC</th>
<td>gkm@fb.com, jezreel@gmail.com, llvm-bugs@lists.llvm.org, smeenai@fb.com
</td>
</tr></table>
<p>
<div>
<pre>(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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>