<div dir="ltr">Thanks, Martin!<div><br></div><div>My biggest question is around the behavior for alias-to-alias linkage. Using Microsoft tools (ml64.exe), if you define an external symbol t2, alias t4 to t2, and alias t7 to t4, you get exactly what you asked for:</div><div><font face="monospace">[ 8](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x00000001 t2<br>[ 9](sec 0)(fl 0x00)(ty 0)(scl 69) (nx 1) 0x00000001 t4<br>AUX indx 8 srch 3<br>[11](sec 0)(fl 0x00)(ty 0)(scl 69) (nx 1) 0x00000001 t7<br>AUX indx 9 srch 3</font></div><br>Using LLVM, we instead get a second weak default-null reference pointing directly to t2, rather than to t4:<br><font face="monospace">[ 3](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x00000001 t2<br>...<br>[ 7](sec 0)(fl 0x00)(ty 0)(scl 69) (nx 1) 0x00000000 t4<br>AUX indx 9 srch 3<br>[ 9](sec 1)(fl 0x00)(ty 0)(scl 69) (nx 0) 0x00000001 .weak.t4.default.t1<br>...<br>[17](sec 0)(fl 0x00)(ty 0)(scl 69) (nx 1) 0x00000000 t7<br>AUX indx 19 srch 3<br>[19](sec 1)(fl 0x00)(ty 0)(scl 69) (nx 0) 0x00000001 .weak.t7.default.t1</font><br><br>Due to our creation of ".weak" intermediates duplicating the current resolution of the aliasee, I think this can result in a different resolution for t7 than would happen in the Microsoft tools case? (Say, in a context where t4 has a strong definition.)<div><br></div><div>Maybe we should eliminate the ".weak" intermediates if the reference's target is already an external symbol? They seem unnecessary for that case.</div><div><br></div><div>Thanks,</div><div>- Eric</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 24, 2020 at 3:49 AM Martin Storsjö <<a href="mailto:martin@martin.st">martin@martin.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On Wed, 23 Sep 2020, Eric Astor via llvm-dev wrote:<br>
<br>
> While working on alias support for the LLVM-ML project, I ran into a feature<br>
> implemented back in 2010: default-null weak externals in COFF, a GNU<br>
> extension.<br>
> <a href="https://reviews.llvm.org/rG17990d56907b" rel="noreferrer" target="_blank">https://reviews.llvm.org/rG17990d56907b</a><br>
> I'd like to disable this feature when targeting MSVC compatibility. Does<br>
> anyone have more context on this, and why it'd be a terrible idea?<br>
> <br>
> For context: This seems to be designed to let LLVM implement a GNU extension<br>
> in COFF libraries. However, it leads to very different behavior than we see<br>
> for cl.exe (and ml.exe) on Windows; for already-defined aliasees, it injects<br>
> an alternate placeholder ".weak.<alias>.default.<uniquifier>" symbol which<br>
> resolves back to the current location. I admit, I'm not quite sure how this<br>
> helps. If anyone can explain the purpose, I'd really appreciate it!<br>
<br>
So, for the GNU extension, from the user point of view, there's two <br>
potential usecases.<br>
<br>
A translation unit can reference a function declaration with <br>
__attribute__((weak)), with no implementation in the translation unit. <br>
This then then either evaluates to NULL or an actual implementation, if <br>
there existed another, non-weak definition in another object file at <br>
link time.<br>
<br>
Secondly, multiple translation units may have function definitions that <br>
are marked with the weak attribute. You can have this in 0-N object files, <br>
and 0-1 object files containing a non-weak definition. If there's no <br>
non-weak definition, one of the weak definitions ends up picked, but if <br>
there is one, the non-weak one ends up used.<br>
<br>
As all this is consumed via GNU style attributes (in MinGW environments), <br>
it shouldn't really matter in an MSVC context.<br>
<br>
I recently worked on this to get the final details on this hooked up for <br>
COFF, so I'd be happy to have a look at any work touching this feature.<br>
<br>
> In Windows PE/COFF files, aliases typically just resolve to their target<br>
> symbol. For an example, see <a href="https://reviews.llvm.org/D87403#inline-811289" rel="noreferrer" target="_blank">https://reviews.llvm.org/D87403#inline-811289</a>.<br>
<br>
For the cases where there already exists a symbol with a name that is <br>
unique in itself, just adding an alias directly to the target symbol <br>
sounds sensible in itself, but for cases when it isn't set up as an alias, <br>
but where the implementation itself is marked weak, the uniquifying symbol <br>
name is needed, to allow multiple objects to provide the same thing.<br>
<br>
Consider these two examples in GAS assembly form:<br>
<br>
.globl uniquename<br>
uniquename:<br>
ret<br>
<br>
.globl func<br>
func:<br>
ret<br>
<br>
.weak aliasname<br>
aliasname = func<br>
<br>
This produces the following symbols, shown with llvm-objdump -t:<br>
<br>
[ 6](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 uniquename<br>
[ 7](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000001 func<br>
[ 8](sec 0)(fl 0x00)(ty 0)(scl 69) (nx 1) 0x00000000 aliasname<br>
AUX indx 10 srch 3 [pointing at .weak.aliasname.default.uniquename]<br>
[10](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000001 .weak.aliasname.default.uniquename<br>
<br>
So here .weak.aliasname.default.uniquename is identical to func, and as <br>
func itself is non-weak, aliasname could just as well have pointed <br>
directly at func instead.<br>
<br>
<br>
But for this case, the extra dance is necessary:<br>
<br>
.globl uniquename<br>
uniquename:<br>
ret<br>
<br>
.weak func<br>
.globl func<br>
func:<br>
ret<br>
<br>
Producing:<br>
[ 6](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 uniquename<br>
[ 7](sec 0)(fl 0x00)(ty 0)(scl 69) (nx 1) 0x00000000 func<br>
AUX indx 9 srch 3<br>
[ 9](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000001 .weak.func.default.uniquename<br>
<br>
<br>
<br>
Initially, the non-weak symbols were just named ".weak.func.default", but <br>
this caused clashes if multiple object files defined the same one. I tried <br>
fixing this in <a href="https://reviews.llvm.org/D71711" rel="noreferrer" target="_blank">https://reviews.llvm.org/D71711</a> by making the non-weak <br>
symbols that the weak ones point at static, but MSVC tools error out if <br>
you have a weak symbol pointing at a non-external symbol (as "weak" in <br>
COFF actually is "weak external"). Therefore I reverted that attempt and I <br>
later made <a href="https://reviews.llvm.org/D75989" rel="noreferrer" target="_blank">https://reviews.llvm.org/D75989</a> that tries to make unique names <br>
for these symbols, to avoid clashes.<br>
<br>
// Martin<br>
</blockquote></div>