Re: PR83775

[Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>]

Hi Prathamesh,

On 10/01/18 19:01, Prathamesh Kulkarni wrote:
> Hi,
> The attached patch tries to fix PR83775.
> Validation in progress.
> OK to commit if passes ?

I've read the relevant PRs and other's inputs on this
(thanks for the perspectives!)
I agree with Richard's design that the driver does all
the smarts of processing the options to create the
right -march string. There's a lot of options,
extensions and variants that we need to keep
track of and having it all in one place in the driver
seems sensible as we need that information there to
drive many other things like multilib selection and
option string rewriting for the other parts of the toolchain.

However, I do agree that being able to debug cc1 directly
is indispensable when working with cross-compilers.
I myself only have the capability of building just a cc1 for
most non-arm (and aarch64) targets when I need to investigate
issues on them. So I'm keen on fixing this segfault.

At this point the end-user-facing experience really requires
them to use the driver to ensure that the assembler, linker
options are correct and the right libraries are selected.
The .arch string we output is for the benefit of the
assembler and if we the user wants the interface to the
assembler to work correctly they should be using the driver
anyway (A cc1 -> gas -> ld pipeline is not a supported pipeline AFAIK).
So setting arch_to_print to the empty string here in order
to not crash looks like a reasonable fix.
Is there some way we can write an assert for the
targ_options->x_arm_arch_string == NULL case to check that we
are indeed invoked without a driver? If so, can you please add one?
Otherwise add a comment saying that cc1 has been invoked directly.

This patch is ok for trunk with either of those changes.

Thanks,
Kyrill

> Thanks,
> Prathamesh