| Message ID | CAMbmDYYKr+2i=k1MHDui59wb4Wk1MteBcDPuAiOZYG+ogGd6ZQ@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Ping 27 февраля 2012 г. 6:41 пользователь Ilya Enkovich <enkovich.gnu@gmail.com> написал: >> You should keep those *_SPEC and define them with new >> GNU_*_SPEC in gnu-user.h since gnu-user.h is also used >> by other non-linux targets. In linux.h, you undef *_SPEC >> before defining them. >> >> >> -- >> H.J. > > Thanks for the note. Here is fixed version. Is it OK now? > > Thanks, > Ilya > -- > 2012-02-27 Enkovich Ilya <ilya.enkovich@intel.com> > > * gcc/config/i386/gnu-user.h (GNU_USER_TARGET_CC1_SPEC): New. > (CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC. > (GNU_USER_TARGET_LINK_SPEC): New. > (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC. > (GNU_USER_TARGET_MATHFILE_SPEC): New. > (ENDFILE_SPEC): Use GNU_USER_TARGET_MATHFILE_SPEC. > > * gcc/config/i386/linux.h (CC1_SPEC): New. > (LINK_SPEC): New. > (LIB_SPEC): New. > (STARTFILE_SPEC): New. > (ENDFILE_SPEC): New. > > > diff --git a/gcc/config/i386/gnu-user.h b/gcc/config/i386/gnu-user.h > index 98d0a25..33ceab7 100644 > --- a/gcc/config/i386/gnu-user.h > +++ b/gcc/config/i386/gnu-user.h > @@ -77,8 +77,11 @@ along with GCC; see the file COPYING3. If not see > #undef CPP_SPEC > #define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}" > > +#undef GNU_USER_TARGET_CC1_SPEC > +#define GNU_USER_TARGET_CC1_SPEC "%(cc1_cpu) %{profile:-p}" > + > #undef CC1_SPEC > -#define CC1_SPEC "%(cc1_cpu) %{profile:-p}" > +#define CC1_SPEC GNU_USER_TARGET_CC1_SPEC > > /* Provide a LINK_SPEC appropriate for GNU userspace. Here we provide support > for the special GCC options -static and -shared, which allow us to > @@ -97,22 +100,28 @@ along with GCC; see the file COPYING3. If not see > { "link_emulation", GNU_USER_LINK_EMULATION },\ > { "dynamic_linker", GNU_USER_DYNAMIC_LINKER } > > -#undef LINK_SPEC > -#define LINK_SPEC "-m %(link_emulation) %{shared:-shared} \ > +#define GNU_USER_TARGET_LINK_SPEC \ > + "-m %(link_emulation) %{shared:-shared} \ > %{!shared: \ > %{!static: \ > %{rdynamic:-export-dynamic} \ > -dynamic-linker %(dynamic_linker)} \ > %{static:-static}}" > > +#undef LINK_SPEC > +#define LINK_SPEC GNU_USER_TARGET_LINK_SPEC > + > /* Similar to standard GNU userspace, but adding -ffast-math support. */ > -#undef ENDFILE_SPEC > -#define ENDFILE_SPEC \ > +#define GNU_USER_TARGET_MATHFILE_SPEC \ > "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \ > %{mpc32:crtprec32.o%s} \ > %{mpc64:crtprec64.o%s} \ > - %{mpc80:crtprec80.o%s} \ > - %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s" > + %{mpc80:crtprec80.o%s}" > + > +#undef ENDFILE_SPEC > +#define ENDFILE_SPEC \ > + GNU_USER_TARGET_MATHFILE_SPEC " " \ > + GNU_USER_TARGET_ENDFILE_SPEC > > /* A C statement (sans semicolon) to output to the stdio stream > FILE the assembler definition of uninitialized global DECL named > diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h > index 73681fe..a832ddc 100644 > --- a/gcc/config/i386/linux.h > +++ b/gcc/config/i386/linux.h > @@ -22,3 +22,30 @@ along with GCC; see the file COPYING3. If not see > > #define GNU_USER_LINK_EMULATION "elf_i386" > #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2" > + > +#undef CC1_SPEC > +#define CC1_SPEC \ > + LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC, \ > + GNU_USER_TARGET_CC1_SPEC " " ANDROID_CC1_SPEC) > + > +#undef LINK_SPEC > +#define LINK_SPEC \ > + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_SPEC, \ > + GNU_USER_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC) > + > +#undef LIB_SPEC > +#define LIB_SPEC \ > + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC, \ > + GNU_USER_TARGET_LIB_SPEC " " ANDROID_LIB_SPEC) > + > +#undef STARTFILE_SPEC > +#define STARTFILE_SPEC \ > + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, \ > + ANDROID_STARTFILE_SPEC) > + > +#undef ENDFILE_SPEC > +#define ENDFILE_SPEC \ > + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_MATHFILE_SPEC " " \ > + GNU_USER_TARGET_ENDFILE_SPEC, \ > + GNU_USER_TARGET_MATHFILE_SPEC " " \ > + ANDROID_ENDFILE_SPEC)
Ping 13 марта 2012 г. 15:13 пользователь Ilya Enkovich <enkovich.gnu@gmail.com> написал: > Ping > > 27 февраля 2012 г. 6:41 пользователь Ilya Enkovich > <enkovich.gnu@gmail.com> написал: >>> You should keep those *_SPEC and define them with new >>> GNU_*_SPEC in gnu-user.h since gnu-user.h is also used >>> by other non-linux targets. In linux.h, you undef *_SPEC >>> before defining them. >>> >>> >>> -- >>> H.J. >> >> Thanks for the note. Here is fixed version. Is it OK now? >> >> Thanks, >> Ilya >> -- >> 2012-02-27 Enkovich Ilya <ilya.enkovich@intel.com> >> >> * gcc/config/i386/gnu-user.h (GNU_USER_TARGET_CC1_SPEC): New. >> (CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC. >> (GNU_USER_TARGET_LINK_SPEC): New. >> (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC. >> (GNU_USER_TARGET_MATHFILE_SPEC): New. >> (ENDFILE_SPEC): Use GNU_USER_TARGET_MATHFILE_SPEC. >> >> * gcc/config/i386/linux.h (CC1_SPEC): New. >> (LINK_SPEC): New. >> (LIB_SPEC): New. >> (STARTFILE_SPEC): New. >> (ENDFILE_SPEC): New. >> >> >> diff --git a/gcc/config/i386/gnu-user.h b/gcc/config/i386/gnu-user.h >> index 98d0a25..33ceab7 100644 >> --- a/gcc/config/i386/gnu-user.h >> +++ b/gcc/config/i386/gnu-user.h >> @@ -77,8 +77,11 @@ along with GCC; see the file COPYING3. If not see >> #undef CPP_SPEC >> #define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}" >> >> +#undef GNU_USER_TARGET_CC1_SPEC >> +#define GNU_USER_TARGET_CC1_SPEC "%(cc1_cpu) %{profile:-p}" >> + >> #undef CC1_SPEC >> -#define CC1_SPEC "%(cc1_cpu) %{profile:-p}" >> +#define CC1_SPEC GNU_USER_TARGET_CC1_SPEC >> >> /* Provide a LINK_SPEC appropriate for GNU userspace. Here we provide support >> for the special GCC options -static and -shared, which allow us to >> @@ -97,22 +100,28 @@ along with GCC; see the file COPYING3. If not see >> { "link_emulation", GNU_USER_LINK_EMULATION },\ >> { "dynamic_linker", GNU_USER_DYNAMIC_LINKER } >> >> -#undef LINK_SPEC >> -#define LINK_SPEC "-m %(link_emulation) %{shared:-shared} \ >> +#define GNU_USER_TARGET_LINK_SPEC \ >> + "-m %(link_emulation) %{shared:-shared} \ >> %{!shared: \ >> %{!static: \ >> %{rdynamic:-export-dynamic} \ >> -dynamic-linker %(dynamic_linker)} \ >> %{static:-static}}" >> >> +#undef LINK_SPEC >> +#define LINK_SPEC GNU_USER_TARGET_LINK_SPEC >> + >> /* Similar to standard GNU userspace, but adding -ffast-math support. */ >> -#undef ENDFILE_SPEC >> -#define ENDFILE_SPEC \ >> +#define GNU_USER_TARGET_MATHFILE_SPEC \ >> "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \ >> %{mpc32:crtprec32.o%s} \ >> %{mpc64:crtprec64.o%s} \ >> - %{mpc80:crtprec80.o%s} \ >> - %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s" >> + %{mpc80:crtprec80.o%s}" >> + >> +#undef ENDFILE_SPEC >> +#define ENDFILE_SPEC \ >> + GNU_USER_TARGET_MATHFILE_SPEC " " \ >> + GNU_USER_TARGET_ENDFILE_SPEC >> >> /* A C statement (sans semicolon) to output to the stdio stream >> FILE the assembler definition of uninitialized global DECL named >> diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h >> index 73681fe..a832ddc 100644 >> --- a/gcc/config/i386/linux.h >> +++ b/gcc/config/i386/linux.h >> @@ -22,3 +22,30 @@ along with GCC; see the file COPYING3. If not see >> >> #define GNU_USER_LINK_EMULATION "elf_i386" >> #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2" >> + >> +#undef CC1_SPEC >> +#define CC1_SPEC \ >> + LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC, \ >> + GNU_USER_TARGET_CC1_SPEC " " ANDROID_CC1_SPEC) >> + >> +#undef LINK_SPEC >> +#define LINK_SPEC \ >> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_SPEC, \ >> + GNU_USER_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC) >> + >> +#undef LIB_SPEC >> +#define LIB_SPEC \ >> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC, \ >> + GNU_USER_TARGET_LIB_SPEC " " ANDROID_LIB_SPEC) >> + >> +#undef STARTFILE_SPEC >> +#define STARTFILE_SPEC \ >> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, \ >> + ANDROID_STARTFILE_SPEC) >> + >> +#undef ENDFILE_SPEC >> +#define ENDFILE_SPEC \ >> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_MATHFILE_SPEC " " \ >> + GNU_USER_TARGET_ENDFILE_SPEC, \ >> + GNU_USER_TARGET_MATHFILE_SPEC " " \ >> + ANDROID_ENDFILE_SPEC)
This patch looks good for Android toolchain. But I am not a maintainer. Can any x86 backend maintainer help to review the patch? Thanks, Jing On Tue, Mar 27, 2012 at 6:55 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote: > Ping > > 13 марта 2012 г. 15:13 пользователь Ilya Enkovich > <enkovich.gnu@gmail.com> написал: >> Ping >> >> 27 февраля 2012 г. 6:41 пользователь Ilya Enkovich >> <enkovich.gnu@gmail.com> написал: >>>> You should keep those *_SPEC and define them with new >>>> GNU_*_SPEC in gnu-user.h since gnu-user.h is also used >>>> by other non-linux targets. In linux.h, you undef *_SPEC >>>> before defining them. >>>> >>>> >>>> -- >>>> H.J. >>> >>> Thanks for the note. Here is fixed version. Is it OK now? >>> >>> Thanks, >>> Ilya >>> -- >>> 2012-02-27 Enkovich Ilya <ilya.enkovich@intel.com> >>> >>> * gcc/config/i386/gnu-user.h (GNU_USER_TARGET_CC1_SPEC): New. >>> (CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC. >>> (GNU_USER_TARGET_LINK_SPEC): New. >>> (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC. >>> (GNU_USER_TARGET_MATHFILE_SPEC): New. >>> (ENDFILE_SPEC): Use GNU_USER_TARGET_MATHFILE_SPEC. >>> >>> * gcc/config/i386/linux.h (CC1_SPEC): New. >>> (LINK_SPEC): New. >>> (LIB_SPEC): New. >>> (STARTFILE_SPEC): New. >>> (ENDFILE_SPEC): New. >>> >>> >>> diff --git a/gcc/config/i386/gnu-user.h b/gcc/config/i386/gnu-user.h >>> index 98d0a25..33ceab7 100644 >>> --- a/gcc/config/i386/gnu-user.h >>> +++ b/gcc/config/i386/gnu-user.h >>> @@ -77,8 +77,11 @@ along with GCC; see the file COPYING3. If not see >>> #undef CPP_SPEC >>> #define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}" >>> >>> +#undef GNU_USER_TARGET_CC1_SPEC >>> +#define GNU_USER_TARGET_CC1_SPEC "%(cc1_cpu) %{profile:-p}" >>> + >>> #undef CC1_SPEC >>> -#define CC1_SPEC "%(cc1_cpu) %{profile:-p}" >>> +#define CC1_SPEC GNU_USER_TARGET_CC1_SPEC >>> >>> /* Provide a LINK_SPEC appropriate for GNU userspace. Here we provide support >>> for the special GCC options -static and -shared, which allow us to >>> @@ -97,22 +100,28 @@ along with GCC; see the file COPYING3. If not see >>> { "link_emulation", GNU_USER_LINK_EMULATION },\ >>> { "dynamic_linker", GNU_USER_DYNAMIC_LINKER } >>> >>> -#undef LINK_SPEC >>> -#define LINK_SPEC "-m %(link_emulation) %{shared:-shared} \ >>> +#define GNU_USER_TARGET_LINK_SPEC \ >>> + "-m %(link_emulation) %{shared:-shared} \ >>> %{!shared: \ >>> %{!static: \ >>> %{rdynamic:-export-dynamic} \ >>> -dynamic-linker %(dynamic_linker)} \ >>> %{static:-static}}" >>> >>> +#undef LINK_SPEC >>> +#define LINK_SPEC GNU_USER_TARGET_LINK_SPEC >>> + >>> /* Similar to standard GNU userspace, but adding -ffast-math support. */ >>> -#undef ENDFILE_SPEC >>> -#define ENDFILE_SPEC \ >>> +#define GNU_USER_TARGET_MATHFILE_SPEC \ >>> "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \ >>> %{mpc32:crtprec32.o%s} \ >>> %{mpc64:crtprec64.o%s} \ >>> - %{mpc80:crtprec80.o%s} \ >>> - %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s" >>> + %{mpc80:crtprec80.o%s}" >>> + >>> +#undef ENDFILE_SPEC >>> +#define ENDFILE_SPEC \ >>> + GNU_USER_TARGET_MATHFILE_SPEC " " \ >>> + GNU_USER_TARGET_ENDFILE_SPEC >>> >>> /* A C statement (sans semicolon) to output to the stdio stream >>> FILE the assembler definition of uninitialized global DECL named >>> diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h >>> index 73681fe..a832ddc 100644 >>> --- a/gcc/config/i386/linux.h >>> +++ b/gcc/config/i386/linux.h >>> @@ -22,3 +22,30 @@ along with GCC; see the file COPYING3. If not see >>> >>> #define GNU_USER_LINK_EMULATION "elf_i386" >>> #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2" >>> + >>> +#undef CC1_SPEC >>> +#define CC1_SPEC \ >>> + LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC, \ >>> + GNU_USER_TARGET_CC1_SPEC " " ANDROID_CC1_SPEC) >>> + >>> +#undef LINK_SPEC >>> +#define LINK_SPEC \ >>> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_SPEC, \ >>> + GNU_USER_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC) >>> + >>> +#undef LIB_SPEC >>> +#define LIB_SPEC \ >>> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC, \ >>> + GNU_USER_TARGET_LIB_SPEC " " ANDROID_LIB_SPEC) >>> + >>> +#undef STARTFILE_SPEC >>> +#define STARTFILE_SPEC \ >>> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, \ >>> + ANDROID_STARTFILE_SPEC) >>> + >>> +#undef ENDFILE_SPEC >>> +#define ENDFILE_SPEC \ >>> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_MATHFILE_SPEC " " \ >>> + GNU_USER_TARGET_ENDFILE_SPEC, \ >>> + GNU_USER_TARGET_MATHFILE_SPEC " " \ >>> + ANDROID_ENDFILE_SPEC)
On 28/02/2012, at 3:41 AM, Ilya Enkovich wrote: >> You should keep those *_SPEC and define them with new >> GNU_*_SPEC in gnu-user.h since gnu-user.h is also used >> by other non-linux targets. In linux.h, you undef *_SPEC >> before defining them. >> >> >> -- >> H.J. > > Thanks for the note. Here is fixed version. Is it OK now? This version looks mostly OK, but still needs a bit of work and testing. How did you test this patch? You should have built before- and after-patch compilers for both Linux and Android and run regression testsuites at least for Linux, and make sure there are no new failures. As is, it appears this patch did not see much testing, I'm pretty sure it breaks building shared libraries and PIE executable for Linux. > > Thanks, > Ilya > -- > 2012-02-27 Enkovich Ilya <ilya.enkovich@intel.com> > > * gcc/config/i386/gnu-user.h (GNU_USER_TARGET_CC1_SPEC): New. > (CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC. > (GNU_USER_TARGET_LINK_SPEC): New. > (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC. > (GNU_USER_TARGET_MATHFILE_SPEC): New. > (ENDFILE_SPEC): Use GNU_USER_TARGET_MATHFILE_SPEC. > > * gcc/config/i386/linux.h (CC1_SPEC): New. > (LINK_SPEC): New. > (LIB_SPEC): New. > (STARTFILE_SPEC): New. > (ENDFILE_SPEC): New. > > > diff --git a/gcc/config/i386/gnu-user.h b/gcc/config/i386/gnu-user.h > index 98d0a25..33ceab7 100644 > --- a/gcc/config/i386/gnu-user.h > +++ b/gcc/config/i386/gnu-user.h > @@ -77,8 +77,11 @@ along with GCC; see the file COPYING3. If not see > #undef CPP_SPEC > #define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}" > > +#undef GNU_USER_TARGET_CC1_SPEC > +#define GNU_USER_TARGET_CC1_SPEC "%(cc1_cpu) %{profile:-p}" Here and in other instances below you use "GNU_USER_TARGET_" prefix. I would prefer using a shorter "GNU_USER_" instead unless there is a good reason to add "TARGET" too. > + > #undef CC1_SPEC > -#define CC1_SPEC "%(cc1_cpu) %{profile:-p}" > +#define CC1_SPEC GNU_USER_TARGET_CC1_SPEC > > /* Provide a LINK_SPEC appropriate for GNU userspace. Here we provide support > for the special GCC options -static and -shared, which allow us to > @@ -97,22 +100,28 @@ along with GCC; see the file COPYING3. If not see > { "link_emulation", GNU_USER_LINK_EMULATION },\ > { "dynamic_linker", GNU_USER_DYNAMIC_LINKER } > > -#undef LINK_SPEC > -#define LINK_SPEC "-m %(link_emulation) %{shared:-shared} \ > +#define GNU_USER_TARGET_LINK_SPEC \ > + "-m %(link_emulation) %{shared:-shared} \ > %{!shared: \ > %{!static: \ > %{rdynamic:-export-dynamic} \ > -dynamic-linker %(dynamic_linker)} \ > %{static:-static}}" > > +#undef LINK_SPEC > +#define LINK_SPEC GNU_USER_TARGET_LINK_SPEC > + > /* Similar to standard GNU userspace, but adding -ffast-math support. */ > -#undef ENDFILE_SPEC > -#define ENDFILE_SPEC \ > +#define GNU_USER_TARGET_MATHFILE_SPEC \ > "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \ > %{mpc32:crtprec32.o%s} \ > %{mpc64:crtprec64.o%s} \ > - %{mpc80:crtprec80.o%s} \ > - %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s" > + %{mpc80:crtprec80.o%s}" > + > +#undef ENDFILE_SPEC > +#define ENDFILE_SPEC \ > + GNU_USER_TARGET_MATHFILE_SPEC " " \ > + GNU_USER_TARGET_ENDFILE_SPEC Here you remove "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s". Presumably, you are moving that to GNU_USER[_TARGET]_ENDFILE_SPEC, but you never define it. > > /* A C statement (sans semicolon) to output to the stdio stream > FILE the assembler definition of uninitialized global DECL named > diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h > index 73681fe..a832ddc 100644 > --- a/gcc/config/i386/linux.h > +++ b/gcc/config/i386/linux.h i386/linux.h is used only for simple x86 32-bit builds; i386/linux64.h is used for multilib-enabled x86 toolchains. Placing below definitions in i386/linux.h will not allow adding an Android as an additional multilib to -m32/-m64 x86 builds. I improve on this situation I suggest: - rename i386/linux.h to i386/linux32.h (with corresponding change to config.gcc), - put below definitions to new i386/linux.h (remember to add license notice header to the new file), - include i386/linux.h from both i386/linux32.h and i386/linux64.h. > @@ -22,3 +22,30 @@ along with GCC; see the file COPYING3. If not see > > #define GNU_USER_LINK_EMULATION "elf_i386" > #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2" > + > +#undef CC1_SPEC > +#define CC1_SPEC \ > + LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC, \ > + GNU_USER_TARGET_CC1_SPEC " " ANDROID_CC1_SPEC) > + > +#undef LINK_SPEC > +#define LINK_SPEC \ > + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_SPEC, \ > + GNU_USER_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC) > + > +#undef LIB_SPEC > +#define LIB_SPEC \ > + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC, \ > + GNU_USER_TARGET_LIB_SPEC " " ANDROID_LIB_SPEC) > + > +#undef STARTFILE_SPEC > +#define STARTFILE_SPEC \ > + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, \ > + ANDROID_STARTFILE_SPEC) > + > +#undef ENDFILE_SPEC > +#define ENDFILE_SPEC \ > + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_MATHFILE_SPEC " " \ > + GNU_USER_TARGET_ENDFILE_SPEC, \ > + GNU_USER_TARGET_MATHFILE_SPEC " " \ > + ANDROID_ENDFILE_SPEC) -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics
> 2012-02-27 Enkovich Ilya <ilya.enkovich@intel.com> > > * gcc/config/i386/gnu-user.h (GNU_USER_TARGET_CC1_SPEC): New. > (CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC. > (GNU_USER_TARGET_LINK_SPEC): New. > (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC. > (GNU_USER_TARGET_MATHFILE_SPEC): New. > (ENDFILE_SPEC): Use GNU_USER_TARGET_MATHFILE_SPEC. > > * gcc/config/i386/linux.h (CC1_SPEC): New. > (LINK_SPEC): New. > (LIB_SPEC): New. > (STARTFILE_SPEC): New. > (ENDFILE_SPEC): New. OK. I guess the patch now follows quite closely the arm implementation, right? I am not quite sure if it makes sense to go around hassle and breaking up the following into generic linux-or-android.h? Honza > diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h > index 73681fe..a832ddc 100644 > --- a/gcc/config/i386/linux.h > +++ b/gcc/config/i386/linux.h > @@ -22,3 +22,30 @@ along with GCC; see the file COPYING3. If not see > > #define GNU_USER_LINK_EMULATION "elf_i386" > #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2" > + > +#undef CC1_SPEC > +#define CC1_SPEC \ > + LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC, \ > + GNU_USER_TARGET_CC1_SPEC " " ANDROID_CC1_SPEC) > + > +#undef LINK_SPEC > +#define LINK_SPEC \ > + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_SPEC, \ > + GNU_USER_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC) > + > +#undef LIB_SPEC > +#define LIB_SPEC \ > + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC, \ > + GNU_USER_TARGET_LIB_SPEC " " ANDROID_LIB_SPEC) > + > +#undef STARTFILE_SPEC > +#define STARTFILE_SPEC \ > + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, \ > + ANDROID_STARTFILE_SPEC) > + > +#undef ENDFILE_SPEC > +#define ENDFILE_SPEC \ > + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_MATHFILE_SPEC " " \ > + GNU_USER_TARGET_ENDFILE_SPEC, \ > + GNU_USER_TARGET_MATHFILE_SPEC " " \ > + ANDROID_ENDFILE_SPEC)
Hello Maxim, Thanks a lot for review. My comments are below. > On 28/02/2012, at 3:41 AM, Ilya Enkovich wrote: > >>> You should keep those *_SPEC and define them with new >>> GNU_*_SPEC in gnu-user.h since gnu-user.h is also used >>> by other non-linux targets. In linux.h, you undef *_SPEC >>> before defining them. >>> >>> >>> -- >>> H.J. >> >> Thanks for the note. Here is fixed version. Is it OK now? > > This version looks mostly OK, but still needs a bit of work and testing. > > How did you test this patch? You should have built before- and after-patch compilers for both Linux and Android and run regression testsuites at least for Linux, and make sure there are no new failures. > > As is, it appears this patch did not see much testing, I'm pretty sure it breaks building shared libraries and PIE executable for Linux. I do not expect any changes in compiler behavior for non Android targets. I bootstrapped and checked patched compiler on linux-x86_64. I also built ptched compiler for Android target using NDK scripts. > > >> >> Thanks, >> Ilya >> -- >> 2012-02-27 Enkovich Ilya <ilya.enkovich@intel.com> >> >> * gcc/config/i386/gnu-user.h (GNU_USER_TARGET_CC1_SPEC): New. >> (CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC. >> (GNU_USER_TARGET_LINK_SPEC): New. >> (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC. >> (GNU_USER_TARGET_MATHFILE_SPEC): New. >> (ENDFILE_SPEC): Use GNU_USER_TARGET_MATHFILE_SPEC. >> >> * gcc/config/i386/linux.h (CC1_SPEC): New. >> (LINK_SPEC): New. >> (LIB_SPEC): New. >> (STARTFILE_SPEC): New. >> (ENDFILE_SPEC): New. >> >> >> diff --git a/gcc/config/i386/gnu-user.h b/gcc/config/i386/gnu-user.h >> index 98d0a25..33ceab7 100644 >> --- a/gcc/config/i386/gnu-user.h >> +++ b/gcc/config/i386/gnu-user.h >> @@ -77,8 +77,11 @@ along with GCC; see the file COPYING3. If not see >> #undef CPP_SPEC >> #define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}" >> >> +#undef GNU_USER_TARGET_CC1_SPEC >> +#define GNU_USER_TARGET_CC1_SPEC "%(cc1_cpu) %{profile:-p}" > > Here and in other instances below you use "GNU_USER_TARGET_" prefix. I would prefer using a shorter "GNU_USER_" instead unless there is a good reason to add "TARGET" too. The reason is that some macroses are defined in other files and I just redefine them (i.e. GNU_USER_TARGET_CC1_SPEC). This prefix is also used for other targets (i.e. in linux-eabi.h). So I do not see a good reason to change it everywhere or mix it with other prefix "GNU_USER_". > >> + >> #undef CC1_SPEC >> -#define CC1_SPEC "%(cc1_cpu) %{profile:-p}" >> +#define CC1_SPEC GNU_USER_TARGET_CC1_SPEC >> >> /* Provide a LINK_SPEC appropriate for GNU userspace. Here we provide support >> for the special GCC options -static and -shared, which allow us to >> @@ -97,22 +100,28 @@ along with GCC; see the file COPYING3. If not see >> { "link_emulation", GNU_USER_LINK_EMULATION },\ >> { "dynamic_linker", GNU_USER_DYNAMIC_LINKER } >> >> -#undef LINK_SPEC >> -#define LINK_SPEC "-m %(link_emulation) %{shared:-shared} \ >> +#define GNU_USER_TARGET_LINK_SPEC \ >> + "-m %(link_emulation) %{shared:-shared} \ >> %{!shared: \ >> %{!static: \ >> %{rdynamic:-export-dynamic} \ >> -dynamic-linker %(dynamic_linker)} \ >> %{static:-static}}" >> >> +#undef LINK_SPEC >> +#define LINK_SPEC GNU_USER_TARGET_LINK_SPEC >> + >> /* Similar to standard GNU userspace, but adding -ffast-math support. */ >> -#undef ENDFILE_SPEC >> -#define ENDFILE_SPEC \ >> +#define GNU_USER_TARGET_MATHFILE_SPEC \ >> "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \ >> %{mpc32:crtprec32.o%s} \ >> %{mpc64:crtprec64.o%s} \ >> - %{mpc80:crtprec80.o%s} \ >> - %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s" >> + %{mpc80:crtprec80.o%s}" >> + >> +#undef ENDFILE_SPEC >> +#define ENDFILE_SPEC \ >> + GNU_USER_TARGET_MATHFILE_SPEC " " \ >> + GNU_USER_TARGET_ENDFILE_SPEC > > Here you remove "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s". Presumably, you are moving that to GNU_USER[_TARGET]_ENDFILE_SPEC, but you never define it. You are right. It is in GNU_USER_TARGET_ENDFILE_SPEC which is defined in gcc/config/gnu-user.h. > >> >> /* A C statement (sans semicolon) to output to the stdio stream >> FILE the assembler definition of uninitialized global DECL named >> diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h >> index 73681fe..a832ddc 100644 >> --- a/gcc/config/i386/linux.h >> +++ b/gcc/config/i386/linux.h > > i386/linux.h is used only for simple x86 32-bit builds; i386/linux64.h is used for multilib-enabled x86 toolchains. Placing below definitions in i386/linux.h will not allow adding an Android as an additional multilib to -m32/-m64 x86 builds. I improve on this situation I suggest: > - rename i386/linux.h to i386/linux32.h (with corresponding change to config.gcc), > - put below definitions to new i386/linux.h (remember to add license notice header to the new file), > - include i386/linux.h from both i386/linux32.h and i386/linux64.h. Android does not support x86_64 target and therefore I do not want -mandroid support for this target. When Android supports x86_64 target this change would be appropriate. > >> @@ -22,3 +22,30 @@ along with GCC; see the file COPYING3. If not see >> >> #define GNU_USER_LINK_EMULATION "elf_i386" >> #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2" >> + >> +#undef CC1_SPEC >> +#define CC1_SPEC \ >> + LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC, \ >> + GNU_USER_TARGET_CC1_SPEC " " ANDROID_CC1_SPEC) >> + >> +#undef LINK_SPEC >> +#define LINK_SPEC \ >> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_SPEC, \ >> + GNU_USER_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC) >> + >> +#undef LIB_SPEC >> +#define LIB_SPEC \ >> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC, \ >> + GNU_USER_TARGET_LIB_SPEC " " ANDROID_LIB_SPEC) >> + >> +#undef STARTFILE_SPEC >> +#define STARTFILE_SPEC \ >> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, \ >> + ANDROID_STARTFILE_SPEC) >> + >> +#undef ENDFILE_SPEC >> +#define ENDFILE_SPEC \ >> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_MATHFILE_SPEC " " \ >> + GNU_USER_TARGET_ENDFILE_SPEC, \ >> + GNU_USER_TARGET_MATHFILE_SPEC " " \ >> + ANDROID_ENDFILE_SPEC) > > > -- > Maxim Kuvyrkov > CodeSourcery / Mentor Graphics > >
Hello Honza, >> 2012-02-27 Enkovich Ilya <ilya.enkovich@intel.com> >> >> * gcc/config/i386/gnu-user.h (GNU_USER_TARGET_CC1_SPEC): New. >> (CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC. >> (GNU_USER_TARGET_LINK_SPEC): New. >> (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC. >> (GNU_USER_TARGET_MATHFILE_SPEC): New. >> (ENDFILE_SPEC): Use GNU_USER_TARGET_MATHFILE_SPEC. >> >> * gcc/config/i386/linux.h (CC1_SPEC): New. >> (LINK_SPEC): New. >> (LIB_SPEC): New. >> (STARTFILE_SPEC): New. >> (ENDFILE_SPEC): New. > OK. > I guess the patch now follows quite closely the arm implementation, right? > I am not quite sure if it makes sense to go around hassle and breaking up > the following into generic linux-or-android.h? Right, impementations are quite close but do not same. For example ENDFILE_SPEC and CC1PLUS_SPEC are defined differently. Therefore we will have target specific parts anyway. Ilya > > Honza > >> diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h >> index 73681fe..a832ddc 100644 >> --- a/gcc/config/i386/linux.h >> +++ b/gcc/config/i386/linux.h >> @@ -22,3 +22,30 @@ along with GCC; see the file COPYING3. If not see >> >> #define GNU_USER_LINK_EMULATION "elf_i386" >> #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2" >> + >> +#undef CC1_SPEC >> +#define CC1_SPEC \ >> + LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC, \ >> + GNU_USER_TARGET_CC1_SPEC " " ANDROID_CC1_SPEC) >> + >> +#undef LINK_SPEC >> +#define LINK_SPEC \ >> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_SPEC, \ >> + GNU_USER_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC) >> + >> +#undef LIB_SPEC >> +#define LIB_SPEC \ >> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC, \ >> + GNU_USER_TARGET_LIB_SPEC " " ANDROID_LIB_SPEC) >> + >> +#undef STARTFILE_SPEC >> +#define STARTFILE_SPEC \ >> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, \ >> + ANDROID_STARTFILE_SPEC) >> + >> +#undef ENDFILE_SPEC >> +#define ENDFILE_SPEC \ >> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_MATHFILE_SPEC " " \ >> + GNU_USER_TARGET_ENDFILE_SPEC, \ >> + GNU_USER_TARGET_MATHFILE_SPEC " " \ >> + ANDROID_ENDFILE_SPEC)
On Sun, Apr 1, 2012 at 8:23 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote: >> i386/linux.h is used only for simple x86 32-bit builds; i386/linux64.h is used for multilib-enabled x86 toolchains. Placing below definitions in i386/linux.h will not allow adding an Android as an additional multilib to -m32/-m64 x86 builds. I improve on this situation I suggest: >> - rename i386/linux.h to i386/linux32.h (with corresponding change to config.gcc), >> - put below definitions to new i386/linux.h (remember to add license notice header to the new file), >> - include i386/linux.h from both i386/linux32.h and i386/linux64.h. > > Android does not support x86_64 target and therefore I do not want > -mandroid support for this target. When Android supports x86_64 target > this change would be appropriate. > Please add x86-64 Android support as suggested by Maxim. It can also be used for x32 Android.
On 2/04/2012, at 3:23 AM, Ilya Enkovich wrote: >> As is, it appears this patch did not see much testing, I'm pretty sure it breaks building shared libraries and PIE executable for Linux. > > I do not expect any changes in compiler behavior for non Android > targets. I bootstrapped and checked patched compiler on linux-x86_64. > I also built ptched compiler for Android target using NDK scripts. OK. >> >> Here and in other instances below you use "GNU_USER_TARGET_" prefix. I would prefer using a shorter "GNU_USER_" instead unless there is a good reason to add "TARGET" too. > > The reason is that some macroses are defined in other files and I just > redefine them (i.e. GNU_USER_TARGET_CC1_SPEC). This prefix is also > used for other targets (i.e. in linux-eabi.h). So I do not see a good > reason to change it everywhere or mix it with other prefix > "GNU_USER_". OK. >> Here you remove "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s". Presumably, you are moving that to GNU_USER[_TARGET]_ENDFILE_SPEC, but you never define it. > > You are right. It is in GNU_USER_TARGET_ENDFILE_SPEC which is defined > in gcc/config/gnu-user.h. OK. I missed that GNU_USER_TARGET_ENDFILE_SPEC was already defined. > >> >>> >>> /* A C statement (sans semicolon) to output to the stdio stream >>> FILE the assembler definition of uninitialized global DECL named >>> diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h >>> index 73681fe..a832ddc 100644 >>> --- a/gcc/config/i386/linux.h >>> +++ b/gcc/config/i386/linux.h >> >> i386/linux.h is used only for simple x86 32-bit builds; i386/linux64.h is used for multilib-enabled x86 toolchains. Placing below definitions in i386/linux.h will not allow adding an Android as an additional multilib to -m32/-m64 x86 builds. I improve on this situation I suggest: >> - rename i386/linux.h to i386/linux32.h (with corresponding change to config.gcc), >> - put below definitions to new i386/linux.h (remember to add license notice header to the new file), >> - include i386/linux.h from both i386/linux32.h and i386/linux64.h. > > Android does not support x86_64 target and therefore I do not want > -mandroid support for this target. When Android supports x86_64 target > this change would be appropriate. The point is that one can build a toolchain for i686-linux-gnu that will support both 32-bit and 64-bit multilibs. The 32-bit multilib will be used by default, and compilation for 64-bit user-space can be requested with -m64 option. Even though Android is not supported for -m64, such a toolchain can support Android as a additional "-m32 -mandroid" multilib. I.e., the toolchain will have three multilibs in total: "-m32" (default), "-m64" and "-m32 -mandroid". I386/linux64.h will be picked up for such a toolchain, even though by default it would compile for 32-bit target. Does this clear up things? Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics
On 30/03/2012, at 6:48 AM, Jan Hubicka wrote: >> 2012-02-27 Enkovich Ilya <ilya.enkovich@intel.com> >> >> * gcc/config/i386/gnu-user.h (GNU_USER_TARGET_CC1_SPEC): New. >> (CC1_SPEC): Use GNU_USER_TARGET_CC1_SPEC. >> (GNU_USER_TARGET_LINK_SPEC): New. >> (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC. >> (GNU_USER_TARGET_MATHFILE_SPEC): New. >> (ENDFILE_SPEC): Use GNU_USER_TARGET_MATHFILE_SPEC. >> >> * gcc/config/i386/linux.h (CC1_SPEC): New. >> (LINK_SPEC): New. >> (LIB_SPEC): New. >> (STARTFILE_SPEC): New. >> (ENDFILE_SPEC): New. > OK. > I guess the patch now follows quite closely the arm implementation, right? > I am not quite sure if it makes sense to go around hassle and breaking up > the following into generic linux-or-android.h? I think this is clear as one can reasonably get. It would be possible to include linux-or-android.h at the end of linux*.h that would #undef/#define *_SPEC macros like below, but it seems clearer to give the final choice of what is going into the *_SPEC macros to individual targets. -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics >> diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h >> index 73681fe..a832ddc 100644 >> --- a/gcc/config/i386/linux.h >> +++ b/gcc/config/i386/linux.h >> @@ -22,3 +22,30 @@ along with GCC; see the file COPYING3. If not see >> >> #define GNU_USER_LINK_EMULATION "elf_i386" >> #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2" >> + >> +#undef CC1_SPEC >> +#define CC1_SPEC \ >> + LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC, \ >> + GNU_USER_TARGET_CC1_SPEC " " ANDROID_CC1_SPEC) >> + >> +#undef LINK_SPEC >> +#define LINK_SPEC \ >> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_SPEC, \ >> + GNU_USER_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC) >> + >> +#undef LIB_SPEC >> +#define LIB_SPEC \ >> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC, \ >> + GNU_USER_TARGET_LIB_SPEC " " ANDROID_LIB_SPEC) >> + >> +#undef STARTFILE_SPEC >> +#define STARTFILE_SPEC \ >> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, \ >> + ANDROID_STARTFILE_SPEC) >> + >> +#undef ENDFILE_SPEC >> +#define ENDFILE_SPEC \ >> + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_MATHFILE_SPEC " " \ >> + GNU_USER_TARGET_ENDFILE_SPEC, \ >> + GNU_USER_TARGET_MATHFILE_SPEC " " \ >> + ANDROID_ENDFILE_SPEC)
> On 2/04/2012, at 3:23 AM, Ilya Enkovich wrote: > >>> As is, it appears this patch did not see much testing, I'm pretty sure it breaks building shared libraries and PIE executable for Linux. >> >> I do not expect any changes in compiler behavior for non Android >> targets. I bootstrapped and checked patched compiler on linux-x86_64. >> I also built ptched compiler for Android target using NDK scripts. > > OK. > >>> >>> Here and in other instances below you use "GNU_USER_TARGET_" prefix. I would prefer using a shorter "GNU_USER_" instead unless there is a good reason to add "TARGET" too. >> >> The reason is that some macroses are defined in other files and I just >> redefine them (i.e. GNU_USER_TARGET_CC1_SPEC). This prefix is also >> used for other targets (i.e. in linux-eabi.h). So I do not see a good >> reason to change it everywhere or mix it with other prefix >> "GNU_USER_". > > OK. > >>> Here you remove "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s". Presumably, you are moving that to GNU_USER[_TARGET]_ENDFILE_SPEC, but you never define it. >> >> You are right. It is in GNU_USER_TARGET_ENDFILE_SPEC which is defined >> in gcc/config/gnu-user.h. > > OK. I missed that GNU_USER_TARGET_ENDFILE_SPEC was already defined. > >> >>> >>>> >>>> /* A C statement (sans semicolon) to output to the stdio stream >>>> FILE the assembler definition of uninitialized global DECL named >>>> diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h >>>> index 73681fe..a832ddc 100644 >>>> --- a/gcc/config/i386/linux.h >>>> +++ b/gcc/config/i386/linux.h >>> >>> i386/linux.h is used only for simple x86 32-bit builds; i386/linux64.h is used for multilib-enabled x86 toolchains. Placing below definitions in i386/linux.h will not allow adding an Android as an additional multilib to -m32/-m64 x86 builds. I improve on this situation I suggest: >>> - rename i386/linux.h to i386/linux32.h (with corresponding change to config.gcc), >>> - put below definitions to new i386/linux.h (remember to add license notice header to the new file), >>> - include i386/linux.h from both i386/linux32.h and i386/linux64.h. >> >> Android does not support x86_64 target and therefore I do not want >> -mandroid support for this target. When Android supports x86_64 target >> this change would be appropriate. > > The point is that one can build a toolchain for i686-linux-gnu that will support both 32-bit and 64-bit multilibs. The 32-bit multilib will be used by default, and compilation for 64-bit user-space can be requested with -m64 option. Even though Android is not supported for -m64, such a toolchain can support Android as a additional "-m32 -mandroid" multilib. I.e., the toolchain will have three multilibs in total: "-m32" (default), "-m64" and "-m32 -mandroid". I386/linux64.h will be picked up for such a toolchain, even though by default it would compile for 32-bit target. Does this clear up things? > I think I see your point. And it seems to make all this work I'll also have to rename i386/gnu-user.h into i386/gnu-user32.h and create i386/gnu-user.h with common definitions to be included by gnu-user[32|64].h. Otherwise I wont be able to use some definitions (i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in linux64.h. Right? Thanks, Ilya > Thank you, > > -- > Maxim Kuvyrkov > CodeSourcery / Mentor Graphics >
On Mon, Apr 2, 2012 at 7:16 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote: >> On 2/04/2012, at 3:23 AM, Ilya Enkovich wrote: >> >>>> As is, it appears this patch did not see much testing, I'm pretty sure it breaks building shared libraries and PIE executable for Linux. >>> >>> I do not expect any changes in compiler behavior for non Android >>> targets. I bootstrapped and checked patched compiler on linux-x86_64. >>> I also built ptched compiler for Android target using NDK scripts. >> >> OK. >> >>>> >>>> Here and in other instances below you use "GNU_USER_TARGET_" prefix. I would prefer using a shorter "GNU_USER_" instead unless there is a good reason to add "TARGET" too. >>> >>> The reason is that some macroses are defined in other files and I just >>> redefine them (i.e. GNU_USER_TARGET_CC1_SPEC). This prefix is also >>> used for other targets (i.e. in linux-eabi.h). So I do not see a good >>> reason to change it everywhere or mix it with other prefix >>> "GNU_USER_". >> >> OK. >> >>>> Here you remove "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s". Presumably, you are moving that to GNU_USER[_TARGET]_ENDFILE_SPEC, but you never define it. >>> >>> You are right. It is in GNU_USER_TARGET_ENDFILE_SPEC which is defined >>> in gcc/config/gnu-user.h. >> >> OK. I missed that GNU_USER_TARGET_ENDFILE_SPEC was already defined. >> >>> >>>> >>>>> >>>>> /* A C statement (sans semicolon) to output to the stdio stream >>>>> FILE the assembler definition of uninitialized global DECL named >>>>> diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h >>>>> index 73681fe..a832ddc 100644 >>>>> --- a/gcc/config/i386/linux.h >>>>> +++ b/gcc/config/i386/linux.h >>>> >>>> i386/linux.h is used only for simple x86 32-bit builds; i386/linux64.h is used for multilib-enabled x86 toolchains. Placing below definitions in i386/linux.h will not allow adding an Android as an additional multilib to -m32/-m64 x86 builds. I improve on this situation I suggest: >>>> - rename i386/linux.h to i386/linux32.h (with corresponding change to config.gcc), >>>> - put below definitions to new i386/linux.h (remember to add license notice header to the new file), >>>> - include i386/linux.h from both i386/linux32.h and i386/linux64.h. >>> >>> Android does not support x86_64 target and therefore I do not want >>> -mandroid support for this target. When Android supports x86_64 target >>> this change would be appropriate. >> >> The point is that one can build a toolchain for i686-linux-gnu that will support both 32-bit and 64-bit multilibs. The 32-bit multilib will be used by default, and compilation for 64-bit user-space can be requested with -m64 option. Even though Android is not supported for -m64, such a toolchain can support Android as a additional "-m32 -mandroid" multilib. I.e., the toolchain will have three multilibs in total: "-m32" (default), "-m64" and "-m32 -mandroid". I386/linux64.h will be picked up for such a toolchain, even though by default it would compile for 32-bit target. Does this clear up things? >> > > I think I see your point. And it seems to make all this work I'll also > have to rename i386/gnu-user.h into i386/gnu-user32.h and create > i386/gnu-user.h with common definitions to be included by > gnu-user[32|64].h. Otherwise I wont be able to use some definitions > (i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in > linux64.h. Right? > I think it is a good idea. Thanks.
On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote: >> >> The point is that one can build a toolchain for i686-linux-gnu that will support both 32-bit and 64-bit multilibs. The 32-bit multilib will be used by default, and compilation for 64-bit user-space can be requested with -m64 option. Even though Android is not supported for -m64, such a toolchain can support Android as a additional "-m32 -mandroid" multilib. I.e., the toolchain will have three multilibs in total: "-m32" (default), "-m64" and "-m32 -mandroid". I386/linux64.h will be picked up for such a toolchain, even though by default it would compile for 32-bit target. Does this clear up things? >> > > I think I see your point. And it seems to make all this work I'll also > have to rename i386/gnu-user.h into i386/gnu-user32.h and create > i386/gnu-user.h with common definitions to be included by > gnu-user[32|64].h. Otherwise I wont be able to use some definitions > (i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in > linux64.h. Right? It's simpler that you think. The target headers ($tm_file in config.gcc -- gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, which serves as proxy to all those headers. All definitions made in preceding headers are available in subsequent headers. So, given that i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only need to touch linux*.h. Thanks, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics
> On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote: > >>> >>> The point is that one can build a toolchain for i686-linux-gnu that will support both 32-bit and 64-bit multilibs. The 32-bit multilib will be used by default, and compilation for 64-bit user-space can be requested with -m64 option. Even though Android is not supported for -m64, such a toolchain can support Android as a additional "-m32 -mandroid" multilib. I.e., the toolchain will have three multilibs in total: "-m32" (default), "-m64" and "-m32 -mandroid". I386/linux64.h will be picked up for such a toolchain, even though by default it would compile for 32-bit target. Does this clear up things? >>> >> >> I think I see your point. And it seems to make all this work I'll also >> have to rename i386/gnu-user.h into i386/gnu-user32.h and create >> i386/gnu-user.h with common definitions to be included by >> gnu-user[32|64].h. Otherwise I wont be able to use some definitions >> (i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in >> linux64.h. Right? > > It's simpler that you think. The target headers ($tm_file in config.gcc -- gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, which serves as proxy to all those headers. All definitions made in preceding headers are available in subsequent headers. So, given that i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only need to touch linux*.h. > > Thanks, > > -- > Maxim Kuvyrkov > CodeSourcery / Mentor Graphics > Hi, I prepared version with common linux.h and gnu-user.h. Does it look OK? Bootstrapped and checked on linux-x86_64. Thanks, Ilya --- 2012-04-03 Enkovich Ilya <ilya.enkovich@intel.com> * config/i386/linux.h: Renamed to ... * config/i386/linux32.h: ... this. * config/i386/gnu-user.h: Renamed to ... * config/i386/gnu-user32.h: ... this. (CPP_SPEC): Remove. (CC1_SPEC): Remove. (ENDFILE_SPEC): Remove. (GNU_USER_TARGET_LINK_SPEC): New. (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC. * config.gcc: Rename i386/linux.h to i386/linux32.h and i386/gnu-user.h to i386/gnu-user32.h. * config/i386/linux.h: New. * config/i386/gnu-user.h: New. * config/i386/linux64.h: Include i386/linux.h. * config/i386/gnu-user64.h: Include i386/gnu-user.h (CPP_SPEC): Remove. (CC1_SPEC): Remove. (ENDFILE_SPEC): Remove. (GNU_USER_TARGET_LINK_SPEC): New. (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC.
On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote: >> On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote: >> >>>> >>>> The point is that one can build a toolchain for i686-linux-gnu that will support both 32-bit and 64-bit multilibs. The 32-bit multilib will be used by default, and compilation for 64-bit user-space can be requested with -m64 option. Even though Android is not supported for -m64, such a toolchain can support Android as a additional "-m32 -mandroid" multilib. I.e., the toolchain will have three multilibs in total: "-m32" (default), "-m64" and "-m32 -mandroid". I386/linux64.h will be picked up for such a toolchain, even though by default it would compile for 32-bit target. Does this clear up things? >>>> >>> >>> I think I see your point. And it seems to make all this work I'll also >>> have to rename i386/gnu-user.h into i386/gnu-user32.h and create >>> i386/gnu-user.h with common definitions to be included by >>> gnu-user[32|64].h. Otherwise I wont be able to use some definitions >>> (i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in >>> linux64.h. Right? >> >> It's simpler that you think. The target headers ($tm_file in config.gcc -- gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, which serves as proxy to all those headers. All definitions made in preceding headers are available in subsequent headers. So, given that i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only need to touch linux*.h. >> >> Thanks, >> >> -- >> Maxim Kuvyrkov >> CodeSourcery / Mentor Graphics >> > > > Hi, > > I prepared version with common linux.h and gnu-user.h. Does it look OK? > > Bootstrapped and checked on linux-x86_64. > There are so many duplicates in gnu-user64.h and gnu-user32.h. Please move all of them to gnu-user.h. Thanks.
On 4/04/2012, at 2:56 AM, H.J. Lu wrote: > On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote: >>> >>> It's simpler that you think. The target headers ($tm_file in config.gcc -- gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, which serves as proxy to all those headers. All definitions made in preceding headers are available in subsequent headers. So, given that i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only need to touch linux*.h. >>> >>> Thanks, >>> >>> -- >>> Maxim Kuvyrkov >>> CodeSourcery / Mentor Graphics >>> >> >> >> Hi, >> >> I prepared version with common linux.h and gnu-user.h. Does it look OK? >> >> Bootstrapped and checked on linux-x86_64. >> > > There are so many duplicates in gnu-user64.h and gnu-user32.h. > Please move all of them to gnu-user.h. Ilya, Why i386/gnu-user.h had to change at all? It seems like you trying to clean up/simplify stuff in i386/gnu-user.h, but in this case it seems (a) not required for the main purpose of this submission, and (b) excessive. As a side note, if it were up to me, I would merge current i386/linux.h and i386/linux64.h into one file -- i386/linux.h -- instead of having similar definitions spread around. But that would be a clean up in itself, and would require a separate submission. Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics
> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote: >>> On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote: >>> >>>>> >>>>> The point is that one can build a toolchain for i686-linux-gnu that will support both 32-bit and 64-bit multilibs. The 32-bit multilib will be used by default, and compilation for 64-bit user-space can be requested with -m64 option. Even though Android is not supported for -m64, such a toolchain can support Android as a additional "-m32 -mandroid" multilib. I.e., the toolchain will have three multilibs in total: "-m32" (default), "-m64" and "-m32 -mandroid". I386/linux64.h will be picked up for such a toolchain, even though by default it would compile for 32-bit target. Does this clear up things? >>>>> >>>> >>>> I think I see your point. And it seems to make all this work I'll also >>>> have to rename i386/gnu-user.h into i386/gnu-user32.h and create >>>> i386/gnu-user.h with common definitions to be included by >>>> gnu-user[32|64].h. Otherwise I wont be able to use some definitions >>>> (i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in >>>> linux64.h. Right? >>> >>> It's simpler that you think. The target headers ($tm_file in config.gcc -- gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, which serves as proxy to all those headers. All definitions made in preceding headers are available in subsequent headers. So, given that i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only need to touch linux*.h. >>> >>> Thanks, >>> >>> -- >>> Maxim Kuvyrkov >>> CodeSourcery / Mentor Graphics >>> >> >> >> Hi, >> >> I prepared version with common linux.h and gnu-user.h. Does it look OK? >> >> Bootstrapped and checked on linux-x86_64. >> > > There are so many duplicates in gnu-user64.h and gnu-user32.h. > Please move all of them to gnu-user.h. > > Thanks. > > -- > H.J. Hi, Here is a new version with all gnu-user32.h and gnu-user64.h common definitions moved to gnu-user.h. Bootstrapped and checked on linux-x86_64. Thanks, Ilya --- 2012-04-04 Enkovich Ilya <ilya.enkovich@intel.com> * config/i386/linux.h: Renamed to ... * config/i386/linux32.h: ... this. * config/i386/gnu-user.h: Renamed to ... * config/i386/gnu-user32.h: ... this. (CPP_SPEC): Removed. (CC1_SPEC): Removed. (ENDFILE_SPEC): Removed. (DEFAULT_PCC_STRUCT_RETURN): Removed. (TARGET_TLS_DIRECT_SEG_REFS_DEFAULT): Removed. (TARGET_OS_CPP_BUILTINS): Removed. (LIBGCC2_HAS_TF_MODE): Removed. (LIBGCC2_TF_CEXT): Removed. (TF_SIZE): Removed. (TARGET_ASM_FILE_END): Removed. (STACK_CHECK_MOVING_SP): Removed. (STACK_CHECK_STATIC_BUILTIN): Removed. (TARGET_THREAD_SSP_OFFSET): Removed. (TARGET_CAN_SPLIT_STACK): Removed. (TARGET_THREAD_SPLIT_STACK_OFFSET): Removed. (GNU_USER_TARGET_LINK_SPEC): New. (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC. * config.gcc: Rename i386/linux.h to i386/linux32.h and i386/gnu-user.h to i386/gnu-user32.h. * config/i386/linux.h: New. * config/i386/gnu-user.h: New. * config/i386/linux64.h: Include i386/linux.h. * config/i386/gnu-user64.h: Include i386/gnu-user.h (CPP_SPEC): Removed. (CC1_SPEC): Removed. (ENDFILE_SPEC): Removed. (DEFAULT_PCC_STRUCT_RETURN): Removed. (TARGET_TLS_DIRECT_SEG_REFS_DEFAULT): Removed. (TARGET_OS_CPP_BUILTINS): Removed. (LIBGCC2_HAS_TF_MODE): Removed. (LIBGCC2_TF_CEXT): Removed. (TF_SIZE): Removed. (TARGET_ASM_FILE_END): Removed. (STACK_CHECK_MOVING_SP): Removed. (STACK_CHECK_STATIC_BUILTIN): Removed. (TARGET_THREAD_SSP_OFFSET): Removed. (TARGET_CAN_SPLIT_STACK): Removed. (TARGET_THREAD_SPLIT_STACK_OFFSET): Removed. (GNU_USER_TARGET_LINK_SPEC): New. (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC.
> On 4/04/2012, at 2:56 AM, H.J. Lu wrote: > >> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote: >>>> >>>> It's simpler that you think. The target headers ($tm_file in config.gcc -- gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, which serves as proxy to all those headers. All definitions made in preceding headers are available in subsequent headers. So, given that i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only need to touch linux*.h. >>>> >>>> Thanks, >>>> >>>> -- >>>> Maxim Kuvyrkov >>>> CodeSourcery / Mentor Graphics >>>> >>> >>> >>> Hi, >>> >>> I prepared version with common linux.h and gnu-user.h. Does it look OK? >>> >>> Bootstrapped and checked on linux-x86_64. >>> >> >> There are so many duplicates in gnu-user64.h and gnu-user32.h. >> Please move all of them to gnu-user.h. > > Ilya, > > Why i386/gnu-user.h had to change at all? It seems like you trying to clean up/simplify stuff in i386/gnu-user.h, but in this case it seems (a) not required for the main purpose of this submission, and (b) excessive. Hi, Initially my patch introduced few macroses in i386/gnu-user.h to use them in i386/linux.h. After I created new i386/linux.h and included it into i386/linux64.h I got a build failure because new i386/linux.h used these new definition from i386/gnu-user.h and only i386/gnu-user64.h was included into tm.h. So, I renamed i386/gnu-user.h into i386/gnu-user32.h and created new i386/gnu-user.h with these missing definitions. Otherwise I would have to copy all changes made in i386/gnu-user.h to i386/gnu-user64.h. Thanks, Ilya > > As a side note, if it were up to me, I would merge current i386/linux.h and i386/linux64.h into one file -- i386/linux.h -- instead of having similar definitions spread around. But that would be a clean up in itself, and would require a separate submission. > > Thank you, > > -- > Maxim Kuvyrkov > CodeSourcery / Mentor Graphics >
Ping. On Apr 4, 2012 at 1:02, Ilya Enkovich <enkovich.gnu@gmail.com> wrote: >> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote: >>>> On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote: >>>> >>>>>> >>>>>> The point is that one can build a toolchain for i686-linux-gnu that will support both 32-bit and 64-bit multilibs. The 32-bit multilib will be used by default, and compilation for 64-bit user-space can be requested with -m64 option. Even though Android is not supported for -m64, such a toolchain can support Android as a additional "-m32 -mandroid" multilib. I.e., the toolchain will have three multilibs in total: "-m32" (default), "-m64" and "-m32 -mandroid". I386/linux64.h will be picked up for such a toolchain, even though by default it would compile for 32-bit target. Does this clear up things? >>>>>> >>>>> >>>>> I think I see your point. And it seems to make all this work I'll also >>>>> have to rename i386/gnu-user.h into i386/gnu-user32.h and create >>>>> i386/gnu-user.h with common definitions to be included by >>>>> gnu-user[32|64].h. Otherwise I wont be able to use some definitions >>>>> (i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in >>>>> linux64.h. Right? >>>> >>>> It's simpler that you think. The target headers ($tm_file in config.gcc -- gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, which serves as proxy to all those headers. All definitions made in preceding headers are available in subsequent headers. So, given that i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only need to touch linux*.h. >>>> >>>> Thanks, >>>> >>>> -- >>>> Maxim Kuvyrkov >>>> CodeSourcery / Mentor Graphics >>>> >>> >>> >>> Hi, >>> >>> I prepared version with common linux.h and gnu-user.h. Does it look OK? >>> >>> Bootstrapped and checked on linux-x86_64. >>> >> >> There are so many duplicates in gnu-user64.h and gnu-user32.h. >> Please move all of them to gnu-user.h. >> >> Thanks. >> >> -- >> H.J. > > Hi, > > Here is a new version with all gnu-user32.h and gnu-user64.h common > definitions moved to gnu-user.h. > > Bootstrapped and checked on linux-x86_64. > > Thanks, > Ilya > --- > 2012-04-04 Enkovich Ilya <ilya.enkovich@intel.com> > > * config/i386/linux.h: Renamed to ... > * config/i386/linux32.h: ... this. > > * config/i386/gnu-user.h: Renamed to ... > * config/i386/gnu-user32.h: ... this. > (CPP_SPEC): Removed. > (CC1_SPEC): Removed. > (ENDFILE_SPEC): Removed. > (DEFAULT_PCC_STRUCT_RETURN): Removed. > (TARGET_TLS_DIRECT_SEG_REFS_DEFAULT): Removed. > (TARGET_OS_CPP_BUILTINS): Removed. > (LIBGCC2_HAS_TF_MODE): Removed. > (LIBGCC2_TF_CEXT): Removed. > (TF_SIZE): Removed. > (TARGET_ASM_FILE_END): Removed. > (STACK_CHECK_MOVING_SP): Removed. > (STACK_CHECK_STATIC_BUILTIN): Removed. > (TARGET_THREAD_SSP_OFFSET): Removed. > (TARGET_CAN_SPLIT_STACK): Removed. > (TARGET_THREAD_SPLIT_STACK_OFFSET): Removed. > (GNU_USER_TARGET_LINK_SPEC): New. > (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC. > > * config.gcc: Rename i386/linux.h to i386/linux32.h and > i386/gnu-user.h to i386/gnu-user32.h. > > * config/i386/linux.h: New. > > * config/i386/gnu-user.h: New. > > * config/i386/linux64.h: Include i386/linux.h. > > * config/i386/gnu-user64.h: Include i386/gnu-user.h > (CPP_SPEC): Removed. > (CC1_SPEC): Removed. > (ENDFILE_SPEC): Removed. > (DEFAULT_PCC_STRUCT_RETURN): Removed. > (TARGET_TLS_DIRECT_SEG_REFS_DEFAULT): Removed. > (TARGET_OS_CPP_BUILTINS): Removed. > (LIBGCC2_HAS_TF_MODE): Removed. > (LIBGCC2_TF_CEXT): Removed. > (TF_SIZE): Removed. > (TARGET_ASM_FILE_END): Removed. > (STACK_CHECK_MOVING_SP): Removed. > (STACK_CHECK_STATIC_BUILTIN): Removed. > (TARGET_THREAD_SSP_OFFSET): Removed. > (TARGET_CAN_SPLIT_STACK): Removed. > (TARGET_THREAD_SPLIT_STACK_OFFSET): Removed. > (GNU_USER_TARGET_LINK_SPEC): New. > (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC.
On Tue, Apr 3, 2012 at 2:02 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote: >> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote: >>>> On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote: >>>> >>>>>> >>>>>> The point is that one can build a toolchain for i686-linux-gnu that will support both 32-bit and 64-bit multilibs. The 32-bit multilib will be used by default, and compilation for 64-bit user-space can be requested with -m64 option. Even though Android is not supported for -m64, such a toolchain can support Android as a additional "-m32 -mandroid" multilib. I.e., the toolchain will have three multilibs in total: "-m32" (default), "-m64" and "-m32 -mandroid". I386/linux64.h will be picked up for such a toolchain, even though by default it would compile for 32-bit target. Does this clear up things? >>>>>> >>>>> >>>>> I think I see your point. And it seems to make all this work I'll also >>>>> have to rename i386/gnu-user.h into i386/gnu-user32.h and create >>>>> i386/gnu-user.h with common definitions to be included by >>>>> gnu-user[32|64].h. Otherwise I wont be able to use some definitions >>>>> (i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in >>>>> linux64.h. Right? >>>> >>>> It's simpler that you think. The target headers ($tm_file in config.gcc -- gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, which serves as proxy to all those headers. All definitions made in preceding headers are available in subsequent headers. So, given that i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only need to touch linux*.h. >>>> >>>> Thanks, >>>> >>>> -- >>>> Maxim Kuvyrkov >>>> CodeSourcery / Mentor Graphics >>>> >>> >>> >>> Hi, >>> >>> I prepared version with common linux.h and gnu-user.h. Does it look OK? >>> >>> Bootstrapped and checked on linux-x86_64. >>> >> >> There are so many duplicates in gnu-user64.h and gnu-user32.h. >> Please move all of them to gnu-user.h. >> >> Thanks. >> >> -- >> H.J. > > Hi, > > Here is a new version with all gnu-user32.h and gnu-user64.h common > definitions moved to gnu-user.h. > > Bootstrapped and checked on linux-x86_64. > > Thanks, > Ilya > --- > 2012-04-04 Enkovich Ilya <ilya.enkovich@intel.com> > > * config/i386/linux.h: Renamed to ... > * config/i386/linux32.h: ... this. > > * config/i386/gnu-user.h: Renamed to ... > * config/i386/gnu-user32.h: ... this. > (CPP_SPEC): Removed. > (CC1_SPEC): Removed. > (ENDFILE_SPEC): Removed. > (DEFAULT_PCC_STRUCT_RETURN): Removed. > (TARGET_TLS_DIRECT_SEG_REFS_DEFAULT): Removed. > (TARGET_OS_CPP_BUILTINS): Removed. > (LIBGCC2_HAS_TF_MODE): Removed. > (LIBGCC2_TF_CEXT): Removed. > (TF_SIZE): Removed. > (TARGET_ASM_FILE_END): Removed. > (STACK_CHECK_MOVING_SP): Removed. > (STACK_CHECK_STATIC_BUILTIN): Removed. > (TARGET_THREAD_SSP_OFFSET): Removed. > (TARGET_CAN_SPLIT_STACK): Removed. > (TARGET_THREAD_SPLIT_STACK_OFFSET): Removed. > (GNU_USER_TARGET_LINK_SPEC): New. > (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC. > > * config.gcc: Rename i386/linux.h to i386/linux32.h and > i386/gnu-user.h to i386/gnu-user32.h. > > * config/i386/linux.h: New. > > * config/i386/gnu-user.h: New. > > * config/i386/linux64.h: Include i386/linux.h. > > * config/i386/gnu-user64.h: Include i386/gnu-user.h > (CPP_SPEC): Removed. > (CC1_SPEC): Removed. > (ENDFILE_SPEC): Removed. > (DEFAULT_PCC_STRUCT_RETURN): Removed. > (TARGET_TLS_DIRECT_SEG_REFS_DEFAULT): Removed. > (TARGET_OS_CPP_BUILTINS): Removed. > (LIBGCC2_HAS_TF_MODE): Removed. > (LIBGCC2_TF_CEXT): Removed. > (TF_SIZE): Removed. > (TARGET_ASM_FILE_END): Removed. > (STACK_CHECK_MOVING_SP): Removed. > (STACK_CHECK_STATIC_BUILTIN): Removed. > (TARGET_THREAD_SSP_OFFSET): Removed. > (TARGET_CAN_SPLIT_STACK): Removed. > (TARGET_THREAD_SPLIT_STACK_OFFSET): Removed. > (GNU_USER_TARGET_LINK_SPEC): New. > (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC. This is a big change. Maybe it is better to break it into 2 parts: 1. Introduce gnu-user32.h only, which can be reviewed by x86 backend maintainers. Another possibility is to add gnu-user-common.h instead of gnu-user32.h so that no changes to config.gcc are needed. 2. Add Android support, which can reviewed by Android maintainer. Thanks.
> > This is a big change. Maybe it is better to break it into 2 > parts: > > 1. Introduce gnu-user32.h only, which can be reviewed by x86 backend > maintainers. Another possibility is to add gnu-user-common.h instead of > gnu-user32.h so that no changes to config.gcc are needed. > 2. Add Android support, which can reviewed by Android maintainer. > > Thanks. > > -- > H.J. OK, I'll split this patch and send new patches in separate threads. Thanks Ilya
diff --git a/gcc/config/i386/gnu-user.h b/gcc/config/i386/gnu-user.h index 98d0a25..33ceab7 100644 --- a/gcc/config/i386/gnu-user.h +++ b/gcc/config/i386/gnu-user.h @@ -77,8 +77,11 @@ along with GCC; see the file COPYING3. If not see #undef CPP_SPEC #define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}" +#undef GNU_USER_TARGET_CC1_SPEC +#define GNU_USER_TARGET_CC1_SPEC "%(cc1_cpu) %{profile:-p}" + #undef CC1_SPEC -#define CC1_SPEC "%(cc1_cpu) %{profile:-p}" +#define CC1_SPEC GNU_USER_TARGET_CC1_SPEC /* Provide a LINK_SPEC appropriate for GNU userspace. Here we provide support for the special GCC options -static and -shared, which allow us to @@ -97,22 +100,28 @@ along with GCC; see the file COPYING3. If not see { "link_emulation", GNU_USER_LINK_EMULATION },\ { "dynamic_linker", GNU_USER_DYNAMIC_LINKER } -#undef LINK_SPEC -#define LINK_SPEC "-m %(link_emulation) %{shared:-shared} \ +#define GNU_USER_TARGET_LINK_SPEC \ + "-m %(link_emulation) %{shared:-shared} \ %{!shared: \ %{!static: \ %{rdynamic:-export-dynamic} \ -dynamic-linker %(dynamic_linker)} \ %{static:-static}}" +#undef LINK_SPEC +#define LINK_SPEC GNU_USER_TARGET_LINK_SPEC + /* Similar to standard GNU userspace, but adding -ffast-math support. */ -#undef ENDFILE_SPEC -#define ENDFILE_SPEC \ +#define GNU_USER_TARGET_MATHFILE_SPEC \ "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \ %{mpc32:crtprec32.o%s} \ %{mpc64:crtprec64.o%s} \ - %{mpc80:crtprec80.o%s} \ - %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s" + %{mpc80:crtprec80.o%s}" + +#undef ENDFILE_SPEC +#define ENDFILE_SPEC \ + GNU_USER_TARGET_MATHFILE_SPEC " " \ + GNU_USER_TARGET_ENDFILE_SPEC /* A C statement (sans semicolon) to output to the stdio stream FILE the assembler definition of uninitialized global DECL named diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h index 73681fe..a832ddc 100644 --- a/gcc/config/i386/linux.h +++ b/gcc/config/i386/linux.h @@ -22,3 +22,30 @@ along with GCC; see the file COPYING3. If not see #define GNU_USER_LINK_EMULATION "elf_i386" #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2" + +#undef CC1_SPEC +#define CC1_SPEC \ + LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC, \ + GNU_USER_TARGET_CC1_SPEC " " ANDROID_CC1_SPEC) + +#undef LINK_SPEC +#define LINK_SPEC \ + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_SPEC, \ + GNU_USER_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC) + +#undef LIB_SPEC +#define LIB_SPEC \ + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC, \ + GNU_USER_TARGET_LIB_SPEC " " ANDROID_LIB_SPEC) + +#undef STARTFILE_SPEC +#define STARTFILE_SPEC \ + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, \ + ANDROID_STARTFILE_SPEC) + +#undef ENDFILE_SPEC +#define ENDFILE_SPEC \ + LINUX_OR_ANDROID_LD (GNU_USER_TARGET_MATHFILE_SPEC " " \ + GNU_USER_TARGET_ENDFILE_SPEC, \ + GNU_USER_TARGET_MATHFILE_SPEC " " \ + ANDROID_ENDFILE_SPEC)