lto-wrapper.c: Use -flto-partition=none with offloading (PR97179)

(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?

Tobias

-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter

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

On Wed, 23 Sep 2020, 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?

LTRANS usually makes the symbols hidden, not local.  So are you
sure this isn't a target bug (hidden symbols not implemented
but the host compiler obviously having checked that but assuming
the target behaves the same as the host) or a linker bug?

Richard.

> Tobias
> 
> -----------------
> Mentor Graphics (Deutschland) GmbH, Arnulfstra?e 201, 80634 M?nchen / Germany
> Registergericht M?nchen HRB 106955, Gesch?ftsf?hrer: Thomas Heurung, Alexander
> Walter
>

On Wed, 23 Sep 2020, Richard Biener wrote:

> On Wed, 23 Sep 2020, 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?
> 
> LTRANS usually makes the symbols hidden, not local.  So are you
> sure this isn't a target bug (hidden symbols not implemented
> but the host compiler obviously having checked that but assuming
> the target behaves the same as the host) or a linker bug?

See lto/lto-partition.c:promote_symbol btw

Richard.

> Richard.
> 
> > Tobias
> > 
> > -----------------
> > Mentor Graphics (Deutschland) GmbH, Arnulfstra?e 201, 80634 M?nchen / Germany
> > Registergericht M?nchen HRB 106955, Gesch?ftsf?hrer: Thomas Heurung, Alexander
> > Walter
> > 
> 
>