<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>On Oct 8, 2014, at 12:52 PM, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:</div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 8, 2014 at 11:45 AM, Alex Rosenberg <span dir="ltr"><<a href="mailto:alexr@leftfield.org" target="_blank">alexr@leftfield.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This it totally "armchair quarterbacking," but I am a little frustrated that we've come to conflate flavors and targets.<br>
<br>
The original intent of flavors was to internally translate each flavor into a neutral lld-native command line syntax. We now have baked in assumptions of behavior based on flavor.<br>
<br>
If I want to cross-compile from OS X for Windows PECOFF, I don't think it feels correct to use a LINK.EXE command line flavor from OS X and I'd rather use an lld-native flavor.<br></blockquote><div><br></div><div>What do we get by making each flavor's driver to a translator to the "universal" lld driver? The merit is not obvious to me, while I'm sure we would have to invent a new syntax for the unviersal driver and maintain the extra layer.</div></div></div></div></div></blockquote><div><br></div><div>As it currently stands, we have no control over the lld command line, only to accept the existing options from the existing flavors of existing products. We should be able to invent our own options based on whatever ideas we implement.</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Another question is that if we make such universal driver, it will support all the options of all flavors in some way, but what combination of the options are allowed? Some option mapping is obvious; for example --verbose in ld and /verbose in link.exe should be mapped to the same option. However, --entry and /entry should not be mapped to the same option, because their semantics are slightly different. If - lazy is given, should it be interpreted as /delayload when linking PECOFF?</div></div></div></div></div></blockquote><div><br></div><div>Yes, behaviors must be chosen. I don't see much difference here compared with linker scripts vs. ld64's command line versions of those features. In the same way, we need to form a completely capable option set.</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>We may be able to answer all the questions. But it's not clear to me what we get from all that efforts.</div></div></div></div></div></blockquote><div><br></div><div>We get to control our own destiny.</div><div><br></div><div>Alex</div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Alex<br>
<div><div class="h5"><br>
On Oct 7, 2014, at 2:22 PM, Shankar Easwaran <<a href="mailto:shankare@codeaurora.org">shankare@codeaurora.org</a>> wrote:<br>
<br>
> On 10/7/2014 4:10 PM, Nick Kledzik wrote:<br>
>> Shankar,<br>
>><br>
>> Can you give provide a scenario where you want this? I’m not sure what you want here.<br>
><br>
> a) LLVM could be built just for one target(LLVM_TARGETS_TO_BUILD)<br>
> b) With LTO this case might happen more often, where an user would have compiled LLVM just for one architecture and lld would support other architectures that LLVM would not support.<br>
> c) Printing all the targets/flavors that the linker currently supports.<br>
><br>
> On Oct 7, 2014, at 2:03 PM, Shankar Easwaran <<a href="mailto:shankare@codeaurora.org">shankare@codeaurora.org</a>> wrote:<br>
>>> Hi,<br>
>>><br>
>>> I think lld needs to have an infrastructure as part of the build process to build specific flavors and specific targets.<br>
>> This sounds like you want config-time choices (e.g. build a linker to only support ELF/x86 such as for a JIT).<br>
> Yes.<br>
><br>
>>> For this I was thinking that the Registry expand to consider flavors and targets that are part of the build process.<br>
>>><br>
>>> So each flavor/target would register and the Driver would walk through the list of handlers to check if there is a handler defined for that flavor/target.<br>
>> This sounds like you want everything decided at runtime (e.g. all flavors registers all readers).<br>
> Yes, right.<br>
><br>
> Shankar Easwaran<br>
><br>
> --<br>
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br>
><br>
</div></div>> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div></div>
</div></blockquote></body></html>