Re: [RFC,patch] Linker plugin - extend API for offloading corner case (aka: LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook [GCC PR109128])

[Tobias Burnus <tobias@codesourcery.com>]

On 04.05.23 13:02, Richard Biener wrote:
> So since we expect the linker to use the host side table is there a way
> for the plugin to exactly query that

Background - feel free to skip to the next quote / reply bit.

The following is what we have for the host side:

We have (→ libgcc/offloadstuff.c)
#define OFFLOAD_FUNC_TABLE_SECTION_NAME ".gnu.offload_funcs"

* crtoffloadbegin.a with:
const void *const __offload_func_table[0]
   __attribute__ ((__used__, visibility ("hidden"),
                   section (OFFLOAD_FUNC_TABLE_SECTION_NAME))) = { };

* crtoffloadend.a with:
const void *const __offload_funcs_end[0]
   __attribute__ ((__used__, visibility ("hidden"),
                   section (OFFLOAD_FUNC_TABLE_SECTION_NAME))) = { };

* crtoffloadtable.a with:
const void *const __OFFLOAD_TABLE__[]
   __attribute__ ((__visibility__ ("hidden"))) =
{
   &__offload_func_table, &__offload_funcs_end,


Each TU generates an a static array with constructor in that
section – and the values for the constructor are the function
(or variable) addresses, i.e. omp_finish_file has:

       tree funcs_decl = build_decl (UNKNOWN_LOCATION, VAR_DECL,
                                     get_identifier (".offload_func_table"),
                                     funcs_decl_type);
       set_decl_section_name (funcs_decl, OFFLOAD_FUNC_TABLE_SECTION_NAME);

> (the set of symbols the linker
> uses from the object passed to the plugin)?  Because if the linker
> uses something from the file but _not_ the host side offload table
> (-ffunction-sections -fdata-sections) then things would still go
> wrong, right?

Shouldn't this only affect where the functions/variables themselves are
placed to - and not the section in which the two offload-funs/-vars arrays
are placed to, given that it was explicitly set?

At least that's how I understand the GCC documentation and after glancing
at the varasm.c code.

That matches also what I see when using those flags. There are differences
related to, e.g. .text.s1.0._omp_fn.0 but .offload_var_table and
.offload_func_table still look fine.


(Side remark, I am wondering whether we should use "retain" for everything
that goes into the special sections, i.e. whether the following should be added:

+#ifndef ACCEL_COMPILER
+      if (SUPPORTS_SHF_GNU_RETAIN)
+       {
+         DECL_ATTRIBUTES (funcs_decl) = tree_cons (get_identifier ("retain"),
+                                                   NULL_TREE, NULL_TREE);

to omp-offload.c (+ "retain" as __attribute__ in libgcc/offloadstuff.c)?

> Is there a way to connect both in a way that the linker discards
> either if the other isn't present?

I think as soon as the file is used, they are present, at least with 'retain',
even though they might be size-zero arrays.

My attempts to check with get_symbols{_v2,_v3} failed. If I recall correctly,
the way everything it setup for the hash, which includes also the file name,
makes it hard to query something which has not been added by get_symbols.
Even if we added a new interface, implementing it in a generic way and being
compatible with the ld.bfd way of storing symbols as hash might be a bit complex.

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955