On Fri, 26 Oct 2018 at 17:07, Christophe Lyon
<christophe.l...@linaro.org> wrote:
>
> On Tue, 23 Oct 2018 at 17:14, Segher Boessenkool
> <seg...@kernel.crashing.org> wrote:
> >
> > On Tue, Oct 23, 2018 at 02:58:21PM +0100, Richard Earnshaw (lists) wrote:
> > > On 15/10/2018 11:10, Christophe Lyon wrote:
> > > > Do you mean to also make -mfdpic non-existent/rejected when GCC is not
> > > > configured
> > > > for arm-uclinuxfdpiceabi?
> > >
> > > Ideally doesn't exist, so that it doesn't show up in things like --help
> > > when it doesn't work.
> > >
> > > > How to achieve that?
> > >
> > > Good question, I'm not sure, off hand. It might be possible to make the
> > > config machinery add additional opt files, but it's not something I've
> > > tried. You might want to try adding an additional opt file to
> > > extra_options for fdpic targets.
> >
> > That should work yes. You could look at how 476.opt is added for powerpc,
> > it is a comparable situation.
> >
>
> Thanks, I got it to work.
>
> Now back to Richard's original question:
> > I think this needs to be resolved. Either -mfdpic works everywhere, or
> > the option should only be available when configured for -mfdpic.
> It's not that -mfdpic does not work everywhere, rather it is not sufficient
> to use it alone: it should be used along with fpic/fPIC/fpie/fPIE depending
> on the use case.
>
> In practice I don't know if we want to be able to use -mfdpic with a
> arm-linux-gnueabi
> toolchain, or if we are ok to have to use two different toolchains
> when we want to make
> tests/compare code generation in both cases.
>
> The 1st option means I should improve the documentation patch. For the 2nd
> one,
> I have patches in progress (which also imply reworking the doc since the
> option
> would not also be available)
>
Here is an updated doc proposal (that would go in patch #1, without
changing this one):
@item -mfdpic
@opindex mfdpic
Select the FDPIC ABI, which uses function descriptors to represent
pointers to functions. When the compiler is configured for
@code{arm-*-uclinuxfdpiceabi} targets, this option is on by default
and implies @option{-fPIE} if none of the PIC/PIE-related options is
provided. On other targets, it only enables the FDPIC-specific code
generation features, and the user should explicitly provide the
PIC/PIE-related options as needed.
The opposite @option{-mno-fdpic} option is useful (and required) to
build the Linux kernel using the same toolchain as the one used to
build the userland programs.
Is it clearer? Does it read OK?
Thanks
> Christophe
>
>
> >
> > Segher
