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