From: Tobias Burnus <tobias@codesourcery.com>
To: Richard Biener <rguenther@suse.de>
Cc: Binutils <binutils@sourceware.org>,
gcc-patches <gcc-patches@gcc.gnu.org>,
Joseph Myers <joseph@codesourcery.com>
Subject: Re: [RFC,patch] Linker plugin - extend API for offloading corner case (aka: LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook [GCC PR109128])
Date: Thu, 4 May 2023 15:25:24 +0200 [thread overview]
Message-ID: <e21b8175-fe94-6e55-86e8-7936e62ba83b@codesourcery.com> (raw)
In-Reply-To: <nycvar.YFH.7.77.849.2305041100250.4723@jbgna.fhfr.qr>
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
next prev parent reply other threads:[~2023-05-04 13:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-02 17:19 Tobias Burnus
2023-05-04 10:30 ` Tobias Burnus
2023-05-04 11:02 ` Richard Biener
2023-05-04 13:25 ` Tobias Burnus [this message]
2023-05-11 0:40 ` Alan Modra
2023-05-11 7:27 ` Richard Biener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e21b8175-fe94-6e55-86e8-7936e62ba83b@codesourcery.com \
--to=tobias@codesourcery.com \
--cc=binutils@sourceware.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=joseph@codesourcery.com \
--cc=rguenther@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).