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