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
