llvm dev - Jan 2018 - Linker Option support for ELF

Hello all,

There was some interest from a number of a few people about adding support
for embedded linker options to ELF.  This would be an extension that
requires linker support to actually work, but has significant prior art
with PE/COFF as well as MachO both having support for this.

The desire here is to actually add support to LLVM to pass along the
necessary information into the object file.  In order to keep this focused
on that, this thread is specifically for the *backend*, we are not
discussing how to get the information to the backend here at all, but
assuming that the information is present in the same LLVM IR encoding
(llvm.linker-options module metadata string).

In order to have compatibility with existing linkers, I am suggesting the
use of an ELF note.  These are implicitly dropped by the linker so we can
be certain that the options will not end up in the final binary even if the
extension is not supported.  The payload would be a 4-byte version
identifier (to allow future enhancements) and a null-terminated string of
options.

This allows for the backend to be entirely oblivious to the data as the
other backends and allows for extensions in the future without having to
teach the backend anything about the new functionality (again, something
which both of the other file formats support).

As an example of how this can be useful, it would help with Swift support
on Linux where currently the linker options are pushed into a custom
section, and a secondary program is used to extract the options from this
section prior to the linker being invoked.  This adds a lot of complexity
to the driver as well as additional tools being invoked in the build chain
slowing down the build.

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180103/3f4e92db/attachment.html>

Saleem Abdulrasool via llvm-dev <llvm-dev at lists.llvm.org> writes:
> Hello all,
>
> There was some interest from a number of a few people about adding support
> for embedded linker options to ELF.  This would be an extension that
> requires linker support to actually work, but has significant prior art
> with PE/COFF as well as MachO both having support for this.
>
> The desire here is to actually add support to LLVM to pass along the
> necessary information into the object file.  In order to keep this focused
> on that, this thread is specifically for the *backend*, we are not
> discussing how to get the information to the backend here at all, but
> assuming that the information is present in the same LLVM IR encoding
> (llvm.linker-options module metadata string).
>
> In order to have compatibility with existing linkers, I am suggesting the
> use of an ELF note.  These are implicitly dropped by the linker so we can
> be certain that the options will not end up in the final binary even if the
> extension is not supported.
So far LGTM.
> The payload would be a 4-byte version
> identifier (to allow future enhancements) and a null-terminated string of
> options.
>
> This allows for the backend to be entirely oblivious to the data as the
> other backends and allows for extensions in the future without having to
> teach the backend anything about the new functionality (again, something
> which both of the other file formats support).
That is the part I have issues with.

A linker has a lot of command line options, we should not make them part
of the object format. What happens if a file has a -strip-all,
--gc-sections or -pie?

I think the supported features should be explicitly documented and be
encoded a option-number,argument pair.

The format should also be discussed at least with the gnu linker
maintainers and ideally on generic-abi at googlegroups.com.

Cheers,
Rafael

On Wed, Jan 3, 2018 at 4:13 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:
> Saleem Abdulrasool via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
> > Hello all,
> >
> > There was some interest from a number of a few people about adding
> support
> > for embedded linker options to ELF.  This would be an extension that
> > requires linker support to actually work, but has significant prior
art
> > with PE/COFF as well as MachO both having support for this.
> >
> > The desire here is to actually add support to LLVM to pass along the
> > necessary information into the object file.  In order to keep this
> focused
> > on that, this thread is specifically for the *backend*, we are not
> > discussing how to get the information to the backend here at all, but
> > assuming that the information is present in the same LLVM IR encoding
> > (llvm.linker-options module metadata string).
> >
> > In order to have compatibility with existing linkers, I am suggesting
the
> > use of an ELF note.  These are implicitly dropped by the linker so we
can
> > be certain that the options will not end up in the final binary even
if
> the
> > extension is not supported.
>
> So far LGTM.
>
> > The payload would be a 4-byte version
> > identifier (to allow future enhancements) and a null-terminated string
of
> > options.
> >
> > This allows for the backend to be entirely oblivious to the data as
the
> > other backends and allows for extensions in the future without having
to
> > teach the backend anything about the new functionality (again,
something
> > which both of the other file formats support).
>
> That is the part I have issues with.
>
> A linker has a lot of command line options, we should not make them part
> of the object format. What happens if a file has a -strip-all,
> --gc-sections or -pie?
>
> I think the supported features should be explicitly documented and be
> encoded a option-number,argument pair.
>
So you are suggesting that the backend take the opaque blob, peer through
it, map it to something else and then encode that?  This means that every
single new flag (also consider vendor extensions and non-GNU linkers) would
need their own mapping and would need additional support for every single
variant of an option.  This makes adding support for a flag extremely
expensive IMO.  Filtering options or only supporting a subset of them in a
particular linker is still viable in the approach I have proposed.
Emitting a warning on an unsupported flag and dropping it would be a way to
handle this without adding the complexity in the backend and frontend and
so tightly coupling all the  various pieces of the toolchain.

> The format should also be discussed at least with the gnu linker
> maintainers and ideally on generic-abi at googlegroups.com.
>
Sure, sending that along to them is perfectly reasonable.

Cheers,
> Rafael

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180103/d4916ee9/attachment.html>

On Wed, Jan 3, 2018 at 4:02 PM, Saleem Abdulrasool <compnerd at
compnerd.org>
wrote:
> Hello all,
>
> There was some interest from a number of a few people about adding support
> for embedded linker options to ELF.  This would be an extension that
> requires linker support to actually work, but has significant prior art
> with PE/COFF as well as MachO both having support for this.
>
> The desire here is to actually add support to LLVM to pass along the
> necessary information into the object file.  In order to keep this focused
> on that, this thread is specifically for the *backend*, we are not
> discussing how to get the information to the backend here at all, but
> assuming that the information is present in the same LLVM IR encoding
> (llvm.linker-options module metadata string).
>
Do we have agreement about this assumption? I think one main point of
disagreement is how open-ended we want things, and llvm.linker.options
implies, at least at first glance, a very open-ended approach. Can you
describe how open-ended llvm.linker.options is, in fact/in practice? I.e.
what subset of linker options do the COFF/MachO targets actually support?

>
> In order to have compatibility with existing linkers, I am suggesting the
> use of an ELF note.  These are implicitly dropped by the linker so we can
> be certain that the options will not end up in the final binary even if the
> extension is not supported.  The payload would be a 4-byte version
> identifier (to allow future enhancements) and a null-terminated string of
> options.
>
One thing that is on my mind is that the fact that llvm.linker.options is
metadata means it can be dropped. So, playing devil's advocate here, it is
correct for ELF targets to just ignore it (as they currently do AFAIK). if
your intended use case does not actually behave correctly with the
llvm.linker.options dropped, then that suggests that something is fishy.

I guess the fact that llvm.linker.options is currently used for COFF/MachO
suggests that it is not dropped in practice in the situations that matter,
but it does provide some evidence that we may want to move away from
llvm.linker.options. For example, we could let frontends parse legacy
open-ended linker pragmas and emit a new IR format with constrained
semantics.

(also, do you know if the COFF/MachO representation for the linker options
in the .o file can/cannot be dropped? AFAIK, SHT_NOTE can be ignored)

I just find it very fishy to consider linker options as advisory.
Presumably if a user is passing them, then they are required for
correctness.

-- Sean Silva


>
> This allows for the backend to be entirely oblivious to the data as the
> other backends and allows for extensions in the future without having to
> teach the backend anything about the new functionality (again, something
> which both of the other file formats support).
>
> As an example of how this can be useful, it would help with Swift support
> on Linux where currently the linker options are pushed into a custom
> section, and a secondary program is used to extract the options from this
> section prior to the linker being invoked.  This adds a lot of complexity
> to the driver as well as additional tools being invoked in the build chain
> slowing down the build.
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180103/79e10c5b/attachment.html>

We should do this. ELF is the odd duck out that lacks this capability.

I agree with Rafael we should have a whitelist of flags that we support,
but I'd rather leave the syntax as more or less just a response file.
That's basically what's implemented for COFF.

Sent from phone

On Wed, Jan 3, 2018, 4:13 PM Rafael Avila de Espindola via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Saleem Abdulrasool via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
> > Hello all,
> >
> > There was some interest from a number of a few people about adding
> support
> > for embedded linker options to ELF.  This would be an extension that
> > requires linker support to actually work, but has significant prior
art
> > with PE/COFF as well as MachO both having support for this.
> >
> > The desire here is to actually add support to LLVM to pass along the
> > necessary information into the object file.  In order to keep this
> focused
> > on that, this thread is specifically for the *backend*, we are not
> > discussing how to get the information to the backend here at all, but
> > assuming that the information is present in the same LLVM IR encoding
> > (llvm.linker-options module metadata string).
> >
> > In order to have compatibility with existing linkers, I am suggesting
the
> > use of an ELF note.  These are implicitly dropped by the linker so we
can
> > be certain that the options will not end up in the final binary even
if
> the
> > extension is not supported.
>
> So far LGTM.
>
> > The payload would be a 4-byte version
> > identifier (to allow future enhancements) and a null-terminated string
of
> > options.
> >
> > This allows for the backend to be entirely oblivious to the data as
the
> > other backends and allows for extensions in the future without having
to
> > teach the backend anything about the new functionality (again,
something
> > which both of the other file formats support).
>
> That is the part I have issues with.
>
> A linker has a lot of command line options, we should not make them part
> of the object format. What happens if a file has a -strip-all,
> --gc-sections or -pie?
>
> I think the supported features should be explicitly documented and be
> encoded a option-number,argument pair.
>
> The format should also be discussed at least with the gnu linker
> maintainers and ideally on generic-abi at googlegroups.com.
>
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180104/2de3c91d/attachment.html>

On Wed, Jan 3, 2018 at 8:08 PM, Sean Silva <chisophugis at gmail.com>
wrote:
>
>
> On Wed, Jan 3, 2018 at 4:02 PM, Saleem Abdulrasool <compnerd at
compnerd.org>
> wrote:
>
>> Hello all,
>>
>> There was some interest from a number of a few people about adding
>> support for embedded linker options to ELF.  This would be an extension
>> that requires linker support to actually work, but has significant
prior
>> art with PE/COFF as well as MachO both having support for this.
>>
>> The desire here is to actually add support to LLVM to pass along the
>> necessary information into the object file.  In order to keep this
focused
>> on that, this thread is specifically for the *backend*, we are not
>> discussing how to get the information to the backend here at all, but
>> assuming that the information is present in the same LLVM IR encoding
>> (llvm.linker-options module metadata string).
>>
>
> Do we have agreement about this assumption? I think one main point of
> disagreement is how open-ended we want things, and llvm.linker.options
> implies, at least at first glance, a very open-ended approach. Can you
> describe how open-ended llvm.linker.options is, in fact/in practice? I.e.
> what subset of linker options do the COFF/MachO targets actually support?
>
>
This is something which is already well established.  I'm not proposing to
change that.  llvm.linker.options is something which is a string passed by
the frontend.  There is nothing that is interpreted by either side.  This
is not new metadata that I am introducing, it is the existing
infrastructure.  Now, if you like, a newer more restrictive mechanism could
be introduced, but that would be beyond the scope of this change IMO.  Both
of those do not have any restrictions AFAIK; and any control of what they
permit is from the *frontend* side.

>
>> In order to have compatibility with existing linkers, I am suggesting
the
>> use of an ELF note.  These are implicitly dropped by the linker so we
can
>> be certain that the options will not end up in the final binary even if
the
>> extension is not supported.  The payload would be a 4-byte version
>> identifier (to allow future enhancements) and a null-terminated string
of
>> options.
>>
>
> One thing that is on my mind is that the fact that llvm.linker.options is
> metadata means it can be dropped. So, playing devil's advocate here, it
is
> correct for ELF targets to just ignore it (as they currently do AFAIK). if
> your intended use case does not actually behave correctly with the
> llvm.linker.options dropped, then that suggests that something is fishy.
>
Yeah, the metadata can be dropped.  If the metadata is dropped, then
nothing gets embedded into the object file.  The changes being discussed
would be embedding additional metadata into the object file.  A separate
change would be needed to actually process that in the linker as well as
one to the frontend to actually emit the metadata.

> I guess the fact that llvm.linker.options is currently used for COFF/MachO
> suggests that it is not dropped in practice in the situations that matter,
> but it does provide some evidence that we may want to move away from
> llvm.linker.options. For example, we could let frontends parse legacy
> open-ended linker pragmas and emit a new IR format with constrained
> semantics.
>
Right, this is inline with what I was suggesting as a second mechanism for
this that could be designed.  But, again, that is beyond the scope of the
changes that I am proposing.

> (also, do you know if the COFF/MachO representation for the linker
> options  in the .o file can/cannot be dropped? AFAIK, SHT_NOTE can be
> ignored)
>
Well, the content is only in the object files.  The final linked binary
does not contain it (which is why Im abusing the SHT_NOTE).  Do you mean
does the linker ignore it?  Well, if the linker doesn't support the
feature, it would.  In PE/COFF, it is encoded as a special section
(.drectve).  In fact, GNU ld doesn't have as complete of an implementation
as lld/link and does ignore a bunch of options.  MachO has a special load
command (LC_LINKOPT) that encodes this.  But, in both cases, it requires
the linker to interpret it, and if it does not, then the same behavior
would be observed.

> I just find it very fishy to consider linker options as advisory.
> Presumably if a user is passing them, then they are required for
> correctness.
>
>
Sure, but that failure would generally be pretty obvious: linking would
fail.

> -- Sean Silva
>
>
>
>>
>> This allows for the backend to be entirely oblivious to the data as the
>> other backends and allows for extensions in the future without having
to
>> teach the backend anything about the new functionality (again,
something
>> which both of the other file formats support).
>>
>> As an example of how this can be useful, it would help with Swift
support
>> on Linux where currently the linker options are pushed into a custom
>> section, and a secondary program is used to extract the options from
this
>> section prior to the linker being invoked.  This adds a lot of
complexity
>> to the driver as well as additional tools being invoked in the build
chain
>> slowing down the build.
>>
>> --
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>>
>
>

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180103/3734f640/attachment.html>

On Wed, Jan 3, 2018 at 4:02 PM, Saleem Abdulrasool <compnerd at
compnerd.org>
wrote:
> Hello all,
>
> There was some interest from a number of a few people about adding support
> for embedded linker options to ELF.  This would be an extension that
> requires linker support to actually work, but has significant prior art
> with PE/COFF as well as MachO both having support for this.
>
> The desire here is to actually add support to LLVM to pass along the
> necessary information into the object file.  In order to keep this focused
> on that, this thread is specifically for the *backend*, we are not
> discussing how to get the information to the backend here at all, but
> assuming that the information is present in the same LLVM IR encoding
> (llvm.linker-options module metadata string).
>
> In order to have compatibility with existing linkers, I am suggesting the
> use of an ELF note.  These are implicitly dropped by the linker so we can
> be certain that the options will not end up in the final binary even if the
> extension is not supported.  The payload would be a 4-byte version
> identifier (to allow future enhancements) and a null-terminated string of
> options.
>
> This allows for the backend to be entirely oblivious to the data as the
> other backends and allows for extensions in the future without having to
> teach the backend anything about the new functionality (again, something
> which both of the other file formats support).
>
> As an example of how this can be useful, it would help with Swift support
> on Linux where currently the linker options are pushed into a custom
> section, and a secondary program is used to extract the options from this
> section prior to the linker being invoked.  This adds a lot of complexity
> to the driver as well as additional tools being invoked in the build chain
> slowing down the build.
>
I realized that I had missed the link to the change that I had put up due
to the original conversation.  It is available at
https://reviews.llvm.org/D40849 for those who are interested.

> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180104/a043df6d/attachment.html>

Thank you for starting the discussion thread.

In general I'm in favor of the proposal. Defining a generic way to convey
some information from the compiler to the linker is useful, and it looks
like it is just a historical reason that the ELF lacks the feature at the
moment.

This is a scenario in which the feature is useful: when you include math.h,
a compiler (which is driven by some pragma) could added `-lm` to the note
section so that a linker automatically links libm.

I think I'm also in favor of the format, which is essentially runs of
null-terminated strings (*1) that are basically opaque to compilers.

However, you should define as a spec what options are allowed and what
their semantics are. We should not accept arbitrary linker options because
semantics of some linker options cannot be clearly defined when they appear
as embedded options. Just saying "this feature allows you to embed linker
options to object files" is too weak as a specification. You need to
clearly define a list of options that will be supported by linkers with
their clear semantics.

(*1) One of the big annoyances that I noticed when I was implementing the
same feature for COFF is that the COFF's .drctve section that contains
linker options have to be tokenized in the same way as the Windows command
line does. So it needs to interpret double quotes and backslashes correctly
especially when handling space-containing pathnames. This is a design
failure that a COFF file contains just a single string instead of runs of
strings that have already been tokenized.

On Thu, Jan 4, 2018 at 9:02 AM, Saleem Abdulrasool via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello all,
>
> There was some interest from a number of a few people about adding support
> for embedded linker options to ELF.  This would be an extension that
> requires linker support to actually work, but has significant prior art
> with PE/COFF as well as MachO both having support for this.
>
> The desire here is to actually add support to LLVM to pass along the
> necessary information into the object file.  In order to keep this focused
> on that, this thread is specifically for the *backend*, we are not
> discussing how to get the information to the backend here at all, but
> assuming that the information is present in the same LLVM IR encoding
> (llvm.linker-options module metadata string).
>
> In order to have compatibility with existing linkers, I am suggesting the
> use of an ELF note.  These are implicitly dropped by the linker so we can
> be certain that the options will not end up in the final binary even if the
> extension is not supported.  The payload would be a 4-byte version
> identifier (to allow future enhancements) and a null-terminated string of
> options.
>
> This allows for the backend to be entirely oblivious to the data as the
> other backends and allows for extensions in the future without having to
> teach the backend anything about the new functionality (again, something
> which both of the other file formats support).
>
> As an example of how this can be useful, it would help with Swift support
> on Linux where currently the linker options are pushed into a custom
> section, and a secondary program is used to extract the options from this
> section prior to the linker being invoked.  This adds a lot of complexity
> to the driver as well as additional tools being invoked in the build chain
> slowing down the build.
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180105/63bfb31f/attachment.html>

On Fri, Jan 5, 2018 at 2:30 AM Rui Ueyama <ruiu at google.com> wrote:
> Thank you for starting the discussion thread.
>
> In general I'm in favor of the proposal. Defining a generic way to
convey
> some information from the compiler to the linker is useful, and it looks
> like it is just a historical reason that the ELF lacks the feature at the
> moment.
>
> This is a scenario in which the feature is useful: when you include
> math.h, a compiler (which is driven by some pragma) could added `-lm` to
> the note section so that a linker automatically links libm.
>
> I think I'm also in favor of the format, which is essentially runs of
> null-terminated strings (*1) that are basically opaque to compilers.
>
Yes.  However, I think I want to clarify that we want this to be completely
opaque to the backend.  The front end could possibly have some enhancements
to make this better.  But, that will be a separate change, and that
discussion should take place then.  We shouldn’t paint ourselves into a
corner.  Basically, I think that there is some legitimate concerns here,
but they would not be handled at this layer, but above.

However, you should define as a spec what options are allowed and
what
> their semantics are. We should not accept arbitrary linker options because
> semantics of some linker options cannot be clearly defined when they appear
> as embedded options. Just saying "this feature allows you to embed
linker
> options to object files" is too weak as a specification. You need to
> clearly define a list of options that will be supported by linkers with
> their clear semantics.
>
Personally, I would like to see the ability to add support for additional
options without having to modify the compiler.  That said, I think that
there are options which can be scary (e.g. -nopie).  I think that the
linker should make the decision of what it supports and error out on
others.  This allows for us to enhance the support over time without a huge
overhead.  As a starting point, I think that -l and -L are two that would
be interesting.  I can see -u being useful as well, but the point is that
we can slowly grow the support after consideration by delaying the
validation of the options.

(*1) One of the big annoyances that I noticed when I was implementing
the
> same feature for COFF is that the COFF's .drctve section that contains
> linker options have to be tokenized in the same way as the Windows command
> line does. So it needs to interpret double quotes and backslashes correctly
> especially when handling space-containing pathnames. This is a design
> failure that a COFF file contains just a single string instead of runs of
> strings that have already been tokenized.
>
I think that there is room for refinement on this.  The best part is that
the refinement for that is delayed!  It would be best done in the front end
IMO, and we can actually  further discuss and design the feature there.  I
don’t think that we need to be completely blind to the issues we have seen,
but we shouldn’t over constrain either.

On Thu, Jan 4, 2018 at 9:02 AM, Saleem Abdulrasool via llvm-dev
<
> llvm-dev at lists.llvm.org> wrote:
>
>> Hello all,
>>
>> There was some interest from a number of a few people about adding
>> support for embedded linker options to ELF.  This would be an extension
>> that requires linker support to actually work, but has significant
prior
>> art with PE/COFF as well as MachO both having support for this.
>>
>> The desire here is to actually add support to LLVM to pass along the
>> necessary information into the object file.  In order to keep this
focused
>> on that, this thread is specifically for the *backend*, we are not
>> discussing how to get the information to the backend here at all, but
>> assuming that the information is present in the same LLVM IR encoding
>> (llvm.linker-options module metadata string).
>>
>> In order to have compatibility with existing linkers, I am suggesting
the
>> use of an ELF note.  These are implicitly dropped by the linker so we
can
>> be certain that the options will not end up in the final binary even if
the
>> extension is not supported.  The payload would be a 4-byte version
>> identifier (to allow future enhancements) and a null-terminated string
of
>> options.
>>
>> This allows for the backend to be entirely oblivious to the data as the
>> other backends and allows for extensions in the future without having
to
>> teach the backend anything about the new functionality (again,
something
>> which both of the other file formats support).
>>
>> As an example of how this can be useful, it would help with Swift
support
>> on Linux where currently the linker options are pushed into a custom
>> section, and a secondary program is used to extract the options from
this
>> section prior to the linker being invoked.  This adds a lot of
complexity
>> to the driver as well as additional tools being invoked in the build
chain
>> slowing down the build.
>>
>> --
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>> --
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180105/bac949a6/attachment.html>