On 07 Oct 16:30, Jakub Jelinek wrote:
> I think it is useful, doesn't have to be in the initial checkin, but I'd
> certainly prefer if from the (optional) --enable-offload-target argument
> it would figure out everything it needs to add for testing.
> And, if mkoffload isn't flexible enough to be convinced to find it in that
> scenario, it better should be made more flexible.
Ok, then we will implement this in a separate patch.
> I thought .gnu.target_lto* sections hold LTO bytecore and are desirable only
> in the
> ET_REL objects for ld(1)/lto-wrapper purposes. For large programs containing
> large
> target regions the LTO bytecode could be very big, so leaving it in the
> binary is
> undesirable.
Already fixed in kyukhin/gomp4-offload branch.
> For .offload_image_section name, wouldn't it be better to prefix that with
> .gnu?
Renamed to .gnu.offload_images, I'll update the branch tomorrow after testing.
> And, is __gnu_offload_{funcs,vars} named that way just because the plugin
> isn't able to add
> symbols around the sections for you? As it doesn't contain a dot, it would
> collide
> with user declarations put into __attribute__((section
> ("__gnu_offload_funcs"))).
Renamed to .gnu.offload_{funcs,vars}.
Automatically provided symbols __start__*, __stop__* don't work with shared
libraries, since the symbols from exec override the respective symbols in dso.
> Looking at the symbols:
> perhaps it would be better to have . somewhere in the names too, though if
> you are
> accessing that from C or declaring them in C, it might be too hard to bother.
> It is all in reserved namespace anyway, but use two underscores prefix
> instead of one
> for those IMHO.
All these symbols are declared/accessed in C, so I renamed them to __offload_*.
On 07 Oct 16:45, Jakub Jelinek wrote:
> Also, something that I believe has been discussed in the past, but can't
> find it on your wiki page nor in *.opt, are option overrides for the
> offloading target, i.e. some option you can pass to the host compiler driver
> during linking that will tell the driver for which offloading targets (if
> any at all) to produce the offloading support (defaulting to all configured
> offloading target is fine) and optionally what extra options beyond what has
> been passed on the command line should be passed to the offloading compiler.
>
> Say, if I want to link target-1.exe such that it will only support host
> fallback and not x86_64-intelmicemul-linux-gnu , how do I achieve that now?
Unfortunately, this is still under development. I hope to have a working patch
in a week. Now, without it, lto-wrapped builds offload images for all offload
targets, specified during configure.
-- Ilya
