On Wed, Sep 23, 2020 at 02:53:54PM +0200, Tobias Burnus wrote:
> (Pre-remark: the following applies to the host; the offloading
> is only involved as otherwise the (.gnu.)offload_{vars,funcs}
> global variable/table wouldn't exist.)
>
> Due to partitioning, it can happen that the offloading table
> and the functions and variables (which it contains as pointer),
> end up in different ltrans. As the functions and vars end
> up as local symbols – the linker will not associate the entries
> in the table of one ltrans with the symbol from the other ltrans,
> failing with "undefined reference" errors.
>
>
> This could be fixed properly by either placing all vars/funcs
> referenced in the (.gnu.)offload_{vars,funcs} table in the same
> ltrans parition — or by ensuring that those symbols are available.
> For funcs, the latter works by setting TREE_PUBLIC (cf. PR) – but
> I didn't manage to do this for variables. — Hence:
>
> This patch disables lto partitioning if the code has offloading.
>
> OK for mainline? — Or better suggestions how to handle this?
I think we should treat the tables and their content as if the user has
added their own (__attribute__((used))) arrays referencing the same
functions/variables. Like:
void foo1 (void) {}
static void foo2 (void) {}
int var1;
static int var2;
static void *table[] __attribute__((used)) = { (void *)foo1, (void *)foo2,
(void *)&var1, (void *)&var2 };
The partitioning code has to handle this and the tables should follow that.
Whether that means teaching the reference discovery code about these, or
whatever else, dunno.
Jakub
