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
