Re: [PATCH v2][C][ADA] use function descriptors instead of trampolines in C

[Joseph Myers <joseph@codesourcery.com>]

[-- Attachment #1: Type: text/plain, Size: 2804 bytes --]

On Wed, 22 Aug 2018, Uecker, Martin wrote:

> Am Dienstag, den 21.08.2018, 21:34 +0000 schrieb Joseph Myers:
> > On Tue, 21 Aug 2018, Uecker, Martin wrote:
> > 
> > > > I don't see why this is target-specific (if it is, the documentation for 
> > > > users in invoke.texi should explain what targets it works for and what it 
> > > > doesn't work for) anyway.  I'd expect it to be a target-independent 
> > > > feature with a target-independent test or tests.
> > > 
> > > My understanding is that this is a target-independent feature which
> > > has not yet been implemented for all targets. The existing
> > > documentation does not reflect this.
> > 
> > How does one tell which targets do or do not support it?
> 
> There is a target hook
> 
> TARGET_CUSTOM_FUNCTION_DESCRIPTORS
> 
> But I am not sure how to get this information to the testsuite.

Presumably through defining a check_* function in target-supports.exp that 
has a list of targets supporting the feature.  Together with 
cross-references in all the relevant places: the hook documentation in 
target.def (and thus the generated file tm.texi) should say that the list 
in target-supports.exp needs to be kept in sync if changing what targets 
implement the hook, and the list in target-supports.exp should similarly 
have a comment referencing the hook, and the user-level documentation in 
invoke.texi should list the relevant architectures, again with comments 
pointing in both directions between it and the other places needing 
updating when a change is made to the set of architectures supporting the 
feature.

Except: if the feature doesn't work on some targets, I'd expect an attempt 
to use -fno-trampolines on other targets to produce a sorry () message 
from the compiler, so it's immediately obvious to the user that the 
requested semantics are not being achieved.  And once you've got that 
sorry (), it should be something the check_* function can reliably test 
for (try compiling a trivial file with -fno-trampolines and see if it 
works, via check_no_compiler_messages*), so you don't need the list of 
targets in target-supports.exp in that case (but the documentation would 
need to say something about the option giving an error on targets not 
supporting it).

> there seems to be infrastructure to implement this. The information seems
> to come from a "target_info" structure (?) but I do not see where this
> is populated.

target_info comes from DejaGnu.  Sometimes a board file may set variables 
in target_info.  But for anything that is an architecture property of GCC, 
the board file should not need to set it; GCC should know the information 
itself.  The board file is more for describing board-specific information 
(e.g. memory available).

-- 
Joseph S. Myers
joseph@codesourcery.com