Hi Alexandre!
On 2023-12-06T09:36:33+0100, Tobias Burnus <tob...@codesourcery.com> wrote:
> FYI the newly added file libgcc/strub.c of this patch (aka commit
> r14-6201-gf0a90c7d7333fc )
> causes that nvptx does not bootstrap, failing with:
('s%bootstrap%build'.)
> ./gcc/as -v -o strub.o strub.s
> Verifying sm_30 code with sm_50 code generation.
> ptxas -c -o /dev/null strub.o --gpu-name sm_50 -O0
> ptxas strub.o, line 22; error : Arguments mismatch for instruction 'st'
> ptxas strub.o, line 22; error : Unknown symbol '%frame'
> [...]
Per commit r14-6201-gf0a90c7d7333fc7f554b906245c84bdf04d716d7
"Introduce strub: machine-independent stack scrubbing", we have:
A function associated with @code{at-calls} @code{strub} mode
(@code{strub("at-calls")}, or just @code{strub}) undergoes interface
changes. Its callers are adjusted to match the changes, and to scrub
(overwrite with zeros) the stack space used by the called function after
it returns.
As I understand things, this cannot be implemented (at the call site) for
nvptx, given that the callee's stack is not visible there: PTX is unusual
in that the concept of a "standard" stack isn't exposed.
Instead of allowing "strub" pieces that can be implemented, should this
whole machinery generally be disabled (forced '-fstrub=disable', or via a
new target hook?)? The libgcc functions should then not get defined
(thus, linker error upon accidental use), or should just '__builtin_trap'
if that makes more sense? Need an effective-target for the test cases.
Alternatively, we may also leave the generic middle end handling alive,
and 'sorry' (or similar) in the nvptx back end, as necessary?
Grüße
Thomas
-----------------
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
