[cfe-dev] clangd/libclang: how to emulate other compilers?

[Manuel Klimek via cfe-dev]

On Thu, Apr 19, 2018 at 11:33 PM Milian Wolff <mail at milianw.de> wrote:

> On Donnerstag, 19. April 2018 19:49:51 CEST Manuel Klimek wrote:
> > On Thu, Apr 19, 2018 at 12:57 PM Milian Wolff <mail at milianw.de> wrote:
> > > On Donnerstag, 19. April 2018 14:12:21 CEST Manuel Klimek wrote:
> > > <snip>
> > >
> > > > Ah, sorry, I missed the neon part. So this works if we add
> > > > -mcpu=cortex-a15. The problem is that the gcc cross compiler
> apparently
> > >
> > > has
> > >
> > > > that configured at build time, and I'm not sure what the best way is
> to
> > > > figure out the full settings for cpu / fpu and float-abi, but I think
> > >
> > > we'll
> > >
> > > > need to find some way to gather them from the underlying cross
> compiler.
> > >
> > > OK, thanks. This brings us one more step closer towards emulation and
> > > should
> > > be sufficient for the example I have given. So, we now end up with
> these
> > > steps:
> > >
> > > #1: query the target compiler
> > > $ ./gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-
> > > gnueabihf-gcc -xc++ -E -v -dM - < /dev/null
> > >
> > > #2: parse the output for the target:
> > > Target: arm-linux-gnueabihf
> > >
> > > #3: parse the default march GCC argument from:
> > > COLLECT_GCC_OPTIONS='-E' '-v' '-dM' '-march=armv7-a'
> '-mtune=cortex-a9' '-
> > > mfloat-abi=hard' '-mfpu=vfpv3-d16' '-mthumb' '-mtls-dialect=gnu'
> > >
> > > #4: parse the include paths:
> > >
> > > #include <...> search starts here:
> > >
> /home/milian/Downloads/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabih
> > >  f/
> > >
> > > bin/../lib/gcc/arm-linux-gnueabihf/7.2.1/include
> > >
> > >
> /home/milian/Downloads/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabih
> > >  f/
> > >
> > > bin/../lib/gcc/arm-linux-gnueabihf/7.2.1/include-fixed
> > >
> > >
> /home/milian/Downloads/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabih
> > >  f/
> > >
> > >
> bin/../lib/gcc/arm-linux-gnueabihf/7.2.1/../../../../arm-linux-gnueabihf/
> > > include
> > >
> > >
> /home/milian/Downloads/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabih
> > >  f/
> > >
> > > bin/../arm-linux-gnueabihf/libc/usr/include
> > >
> > > #5: exclude the GCC builtin include path, i.e.:
> > >
> /home/milian/Downloads/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabih
> > >  f/
> > >
> > > bin/../lib/gcc/arm-linux-gnueabihf/7.2.1/include
> > >
> > > For now, this can be done by some heuristics, like checking whether the
> > > folder
> > > contains a "varargs.h" file.
> > >
> > > #6: parse the defines and write all into a file that starts with
> `#pragma
> > > clang system_header`
> >
> > This might still break if you define things that the compiler wants to
> > define on its own, so you might need a filter, but overall this looks
> > reasonable now :)
>
> Afaik this shouldn't be an issue: If you don't add the `#pragma clang
> system_header` line at the start of the imacro file, then you are swamped
> by
> redefinition errors/warnings. The pragma just silences these, but are they
> actually redefined or not? From what I've seen, they are redefined, and
> that's
> fine from what I've seen so far...
>
> Can you come up with a scenario where it would break?
>

I'm not sure how likely it's to break. You can basically go through the
builtin headers and look for things that the other compiler might have
defined differently.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180420/37c311a3/attachment.html>