RFC: cross-compile failure in gcc/config/host-linux.c
Hello! I compiled gcc on i486-pc-linux-gnu for i386-unknown-linux-uclibc and with the latter I cross-compiled gcc to be run on the target. For some reason __USE_POSIX is not defined and bits/posix1_lim.h does not get included by limits.h, not defining SSIZE_MAX used in host-linux.c. What is the correct approach? One possibility would be to add #ifndef SSIZE_MAX /* as done in posix1_lim.h */ #define SSIZE_MAX LONG_MAX #endif to host-linux.c? An other option would be to use LONG_MAX instead of SSIZE_MAX. The uclibc support is a backport from trunk. Tested 3.4.6/4.1.1, but trunk is also affected probably. Thanks, Peter Please CC to me, not on list. -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: ld and R_386_GOTOFF relocs
On Wed, 11 May 2005, H. J. Lu wrote: > On Thu, May 12, 2005 at 12:48:46AM +0200, Peter S. Mazinger wrote: > > Hello! > > > > I have gotten under peculiar circumstances following: > > (sysvinit) init.o: relocation R_386_GOTOFF against protected function > > `main' can not be used when making a shared object > > > > libc.so does not provide a weak 'main', main() is in crt1.o defined in asm > > as '.protected main'. > > > > init is built as -pie executable. > > > > I think this check is valid if a shared lib is created, but not valid for > > a PIE executable. > > > > I think, that a check info->shared should be changed to > > info->shared && !info->pie (or !info->executable), to allow pie to be > > linked, but I can't locate the one needed for this. > > > > Thanks, Peter > > This is a gcc bug > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520 Reading through this, I came to the patch you posted on 2005-02-06 for elf32-i386.c. The comment says: +2005-02-06 H.J. Lu <[EMAIL PROTECTED]> + + * elf32-i386.c (elf_i386_relocate_section): Disallow R_386_GOTOFF + against protected function when building shared library. If you intented to do this only for shared libraries, but not for PIE executables, then info->shared is incorrect, and as I proposed has to be changed. Peter -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: ld and R_386_GOTOFF relocs
On Thu, 12 May 2005, H. J. Lu wrote: > On Thu, May 12, 2005 at 08:13:27AM +0200, Peter S. Mazinger wrote: > > On Wed, 11 May 2005, H. J. Lu wrote: > > > > > On Thu, May 12, 2005 at 12:48:46AM +0200, Peter S. Mazinger wrote: > > > > Hello! > > > > > > > > I have gotten under peculiar circumstances following: > > > > (sysvinit) init.o: relocation R_386_GOTOFF against protected function > > > > `main' can not be used when making a shared object > > > > > > > > libc.so does not provide a weak 'main', main() is in crt1.o defined in > > > > asm > > > > as '.protected main'. > > > > > > > > init is built as -pie executable. > > > > > > > > I think this check is valid if a shared lib is created, but not valid > > > > for > > > > a PIE executable. > > > > > > > > I think, that a check info->shared should be changed to > > > > info->shared && !info->pie (or !info->executable), to allow pie to be > > > > linked, but I can't locate the one needed for this. > > > > > > > > Thanks, Peter > > > > > > This is a gcc bug > > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520 > > > > Reading through this, I came to the patch you posted on 2005-02-06 for > > elf32-i386.c. The comment says: > > > > +2005-02-06 H.J. Lu <[EMAIL PROTECTED]> > > + > > + * elf32-i386.c (elf_i386_relocate_section): Disallow R_386_GOTOFF > > + against protected function when building shared library. > > > > If you intented to do this only for shared libraries, but not for PIE > > executables, then info->shared is incorrect, and as I proposed has to be > > changed. > > > > I checked in the following patch. Thanks, your patched solved it. Peter > > FYI, using protected function in executable has no benefit since > noone can override function in executable anyway. > > > H.J. > > 2005-05-12 H.J. Lu <[EMAIL PROTECTED]> > > * elf32-i386.c (elf_i386_relocate_section): Allow R_386_GOTOFF > against protected function when building executable. > > --- bfd/elf32-i386.c.pie 2005-05-12 10:00:49.0 -0700 > +++ bfd/elf32-i386.c 2005-05-12 13:55:04.0 -0700 > @@ -2390,6 +2390,7 @@ elf_i386_relocate_section (bfd *output_b >for shared library since it may not be local when used >as function address. */ > if (info->shared > + && !info->executable > && h > && h->def_regular > && h->type == STT_FUNC > > -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
duplicate -lgcc --as-needed -lgcc_s --no-as-needed
Hello! the sequence used for linking on x86 (but most archs will have it too) -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed contains duplicate. Is this really necessary? Will the '--as-needed -lgcc_s --no-as-needed' ever apply? The missing symbols will be found in -lgcc. Thanks, Peter Please CC to me, not on list. -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: duplicate -lgcc --as-needed -lgcc_s --no-as-needed
On Thu, 2 Jun 2005, Jakub Jelinek wrote: > On Thu, Jun 02, 2005 at 01:59:46PM +0200, Peter S. Mazinger wrote: > > Hello! > > > > the sequence used for linking on x86 (but most archs will have it too) > > -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s > > --no-as-needed > > contains duplicate. Is this really necessary? Is it necessary to have it before -lc and after? > > Will the '--as-needed -lgcc_s --no-as-needed' ever apply? > > > The missing symbols will be found in -lgcc. > > That's not true. The EH stuff is not in -lgcc, so if -lc needs it, > it wouldn't be found. > > Jakub so this construct is used only to get EH stuff from libgcc_s.so? Is there stuff in libgcc.a that is not present in libgcc_s.so too? If not, what about moving this around (or remove -lgcc) and get everything from libgcc_s, if we already depend on it? Peter -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
libssp missing from CVS
Hello! libssp subdir is present in cvs (checked on savannah) but cvs -q upd does not get it. Is it a cvs-server failure or something on my side? Thanks, Peter -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: libssp missing from CVS
On Mon, 5 Sep 2005, Andrew Pinski wrote: > > On Sep 5, 2005, at 11:35 AM, Peter S. Mazinger wrote: > > > Hello! > > > > libssp subdir is present in cvs (checked on savannah) but cvs -q upd > > does > > not get it. Is it a cvs-server failure or something on my side? > > You want to update with "cvs -q up -d -P", -d is required to get the new > directories. I had update -dP in .cvsrc, but it seems it is not interpreted, I'll try it on the commandline, thx Peter -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
apps built w/ -fstack-protector-all segfault
Hello! gcc-4.1.20051105 -fno-stack-protector-all is not recognised/implemented apps built w/ -fstack-protector-all segfault test env: - uClibc-svn - guard is set up like glibc does in ld.so as non-TLS version - libssp is not used, gcc's configure check was enabled to recognize __stack_chk_guard in uClibc Peter PS: please CC to me, not on list, thanks -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: apps built w/ -fstack-protector-all segfault
On Mon, 14 Nov 2005, Jim Wilson wrote: > Peter S. Mazinger wrote: > > -fno-stack-protector-all is not recognised/implemented > > You could just submit this as a bug report into bugzilla. > > > apps built w/ -fstack-protector-all segfault > > You will have to give us more info. Most gcc developers probably don't > have a copy of UClibc, and plus it sounds like you have made gcc changes > that weren't included in your message. So there isn't much we can do sorry, the used gcc patches are those from http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi/trunk/buildroot/toolchain/gcc/4.1.0/#dirlist (these are mostly needed due to gcc missing real uClibc support) > here except ask for more details. Try debugging the problem. If you can't really tell what is going on. I can only say, that I am using the stack protector since gcc 3.3.x in conjunction w/ uClibc (the "original" version), and now that I wanted to test it with newer gcc I have modified the guard setup part in uClibc so that it can both use the old (=gcc-4) guard style and fail (I have mimiced here the glibc non-TLS version for __stack_chk_guard). With gcc-3.4.4 it works well (as earlier), but gcc-4 (I have backported even *_chk and the ssp stuff to 4.0.2) fails. I have really hoped that someone here can duplicate it in any environment (because if fno-stack-protector-all does not even exist, then this part of the code wasn't even tested) There are 2 scenarios were it could behave the same: 1. Using newest glibc (2.3.6 is not enough), you need cvs, so it won't use libssp.so 2. Using any glibc in conjunction w/ libssp.so > can identify a specific problem here, and give us details about it, we > can probably help. what kind of details should I provide? Thanks, Peter -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: apps built w/ -fstack-protector-all segfault
On Mon, 14 Nov 2005, Eric Christopher wrote: > > > >> apps built w/ -fstack-protector-all segfault > > > > You will have to give us more info. Most gcc developers probably > > don't have a copy of UClibc, and plus it sounds like you have made > > gcc changes that weren't included in your message. So there isn't > > much we can do here except ask for more details. Try debugging the > > problem. If you can identify a specific problem here, and give us > > details about it, we can probably help. > > Also since __builtin_trap is used in the fail mechanism the comment > above the trap instruction in i386.md might be useful: This is only true is libssp.so is used, I am using "established, working" exit code, that worked w/ earlier ssp as well (when it was not integrated) I mentioned that I use it as integrated into libc (exactly like glibc-cvs does), glibc uses libc_message iirc for exit. this should also influence the -fstack-protector behaviour, but that seems to be OK. __builtin_trap is used as I can see only if a vulnerability is found, this happens though on a simple hello world. Thanks, Peter > > ;; We used to use "int $5", in honor of #BR which maps to interrupt > vector 5. > ;; That, however, is usually mapped by the OS to SIGSEGV, which is often > ;; caught for use by garbage collectors and the like. Using an insn > that > ;; maps to SIGILL makes it more likely the program will rightfully die. > ;; Keeping with tradition, "6" is in honor of #UD. > > So you may be seeing something mapped odd, or... > > -eric > > -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: apps built w/ -fstack-protector-all segfault
On Mon, 14 Nov 2005, Eric Christopher wrote:
> >
> > this should also influence the -fstack-protector behaviour, but
> > that seems
> > to be OK.
> > __builtin_trap is used as I can see only if a vulnerability is
> > found, this
> > happens though on a simple hello world.
>
> Aaah. You'll probably need to step through the program in a debugger
> then and find out where and why it segfaults.
app:
#include
int main() {
printf("Hello\n");
return 0;
}
I don't really know gdb how to use, but
gdb run:
Program received signal SIGSEGV, Segmentation fault.
main () at tes.c:3
3 int main () {
>bt
#0 main () at tes.c:3
allowing it to core dump and running gdb against the core
#... 0x000 in ?? ()
finally
Error accessing memory address 0xc000: No such file or directory
The same built only w/ -fstack-protector is OK.
What else can I do to help finding the problem?
Apropos: there is another bug probably related to libssp.so use (does not
influence the case here, due to __stack_chk_guard being in libc), it
should write %{fstack-protector|fstack-protector-all: -lssp }, else for
-fstack-protector-all it won't link against libssp.so
Thanks, Peter
--
Peter S. MazingerID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: apps built w/ -fstack-protector-all segfault
On Tue, 15 Nov 2005, James E Wilson wrote: > On Mon, 2005-11-14 at 22:45, Peter S. Mazinger wrote: > > I have really hoped that someone here can duplicate it in any environment > > In that case, I'd suggest creating a bugzilla bug report. The gcc list > is really more of a self-help list for gcc developers. If you want to > try to debug the problem yourself, we may be able to provide useful > advice. If you want someone else to look at it, then just file a bug I wanted to only know if there is a configuration/scenario where this really worked. I would do the testing, I lack the needed gdb/other debug knowledge, if you would be so kind to guide me, I would try to get this working. > report. You may also want to report this to the uClibc developers. > They are probably more interested in looking at this than the gcc > developers. gcc-4.1-pre is "future" music, not even glibc's changes went into 2.3.6 to support these features ... > > > (because if fno-stack-protector-all does not even exist, then this part of > > the code wasn't even tested) > > Isn't this the default? I.e. no stack protection at all is what gcc > does by default. So clearly this has been tested. The only thing > missing is that we don't have an override option, so that you can say > -fstack-protector-all -fno-stack-protector-all and get the default > behaviour back. If you meant something else, then you will need to > explain what you meant. I meant exactly this, gcc supports -fno-stack-protector (although gcc defaults to no-ssp), so -fno-stack-protector-all should be there too Peter -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: apps built w/ -fstack-protector-all segfault
On Wed, 16 Nov 2005, Richard Henderson wrote: > On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote: > > I meant exactly this, gcc supports -fno-stack-protector (although gcc > > defaults to no-ssp), so -fno-stack-protector-all should be there too > > Why? What option would it perform? to have the possibility to override an earlier one, as it is done w/ many fno* options. Why should this one not have it's counterpart. Ex. gcc does not default to fomit-frame-pointer, but we have fno-omit-frame-pointer Peter -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: apps built w/ -fstack-protector-all segfault
On Wed, 16 Nov 2005, Richard Henderson wrote:
> On Wed, Nov 16, 2005 at 08:40:11PM +0100, Peter S. Mazinger wrote:
> > On Wed, 16 Nov 2005, Richard Henderson wrote:
> >
> > > On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote:
> > > > I meant exactly this, gcc supports -fno-stack-protector (although gcc
> > > > defaults to no-ssp), so -fno-stack-protector-all should be there too
> > >
> > > Why? What option would it perform?
> >
> > to have the possibility to override an earlier one, as it is done w/ many
> > fno* options. Why should this one not have it's counterpart.
>
> There are three states we can be in:
>
> (0) no stack protection -fno-stack-protector
> (1) heuristic stack protection -fstack-protector
> (2) all stack protection-fstack-protector-all
>
> All of these three states have corresponding switches. You can
> use any of them at any time.
True for default configs. Let's consider though other distros like
ubuntu/adamantix/gentoo that can default to "(2) all stack protection"
but sometimes, due to problems (mainly c++) -all has to be disabled.
-fno-stack-protector would disable all the protection, that is not what
would be needed.
> But what does -fno-stack-protector-all mean? I claim it doesn't
> mean anything at all, and is useless. I claim you either wanted
> -fstack-protector or -fno-stack-protector.
to illustrate how the above is currently done (specs, cc1)
%{!fno-stack-protector:-fstack-protector
%{!fno-stack-protector-all:-fstack-protector-all}}
Peter
--
Peter S. MazingerID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: apps built w/ -fstack-protector-all segfault
On Wed, 16 Nov 2005, Richard Henderson wrote: > On Wed, Nov 16, 2005 at 10:02:23PM +0100, Peter S. Mazinger wrote: > > On Wed, 16 Nov 2005, Richard Henderson wrote: > > > > > On Wed, Nov 16, 2005 at 08:40:11PM +0100, Peter S. Mazinger wrote: > > > > On Wed, 16 Nov 2005, Richard Henderson wrote: > > > > > > > > > On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote: > > > > > > I meant exactly this, gcc supports -fno-stack-protector (although > > > > > > gcc > > > > > > defaults to no-ssp), so -fno-stack-protector-all should be there too > > > > > > > > > > Why? What option would it perform? > > > > > > > > to have the possibility to override an earlier one, as it is done w/ > > > > many > > > > fno* options. Why should this one not have it's counterpart. > > > > > > There are three states we can be in: > > > > > > (0) no stack protection -fno-stack-protector > > > (1) heuristic stack protection -fstack-protector > > > (2) all stack protection-fstack-protector-all > > > > > > All of these three states have corresponding switches. You can > > > use any of them at any time. > > > > True for default configs. Let's consider though other distros like > > ubuntu/adamantix/gentoo that can default to "(2) all stack protection" > > but sometimes, due to problems (mainly c++) -all has to be disabled. > > -fno-stack-protector would disable all the protection, that is not what > > would be needed. > > Use -fstack-protector to return to state (1). you missed the example earlier, or the behaviour of these 2 flags are not like they were earlier. what happens w/ -fstack-protector-all -fstack-protector (in this order) ? do we have (2) or (1) If the order is relevant then (1) will apply. so now it does -fstack-protector #define __SSP__ 1 ; #undef __SSP_ALL__ -fstack-protector-all #define __SSP_ALL__ 2 ; #undef __SSP__ and the last wins. I think this is not quite correct, because -all is a superset of -fstack-protector, so it also should define __SSP__ 1 Peter -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: apps built w/ -fstack-protector-all segfault
On Wed, 16 Nov 2005, Richard Henderson wrote: > On Wed, Nov 16, 2005 at 10:32:45PM +0100, Peter S. Mazinger wrote: > > what happens w/ -fstack-protector-all -fstack-protector (in this order) ? > > do we have (2) or (1) > > We have 1. > > > so now it does > > -fstack-protector #define __SSP__ 1 ; #undef __SSP_ALL__ > > -fstack-protector-all #define __SSP_ALL__ 2 ; #undef __SSP__ > > > > and the last wins. > > I don't know what you're looking at, but it isn't mainline. > The defines are not controled this way. The defines are exactly like this (only undef is not done, because the last wins) so -fstack-protector -fstack-protector-all will have only __SSP_ALL__ 2 -fstack-protector-all -fstack-protector will have only __SSP__ 1 so in any case the last wins -fstack-protector-all (all protection) being superset of -fstack-protector (random protection) it should also define __SSP__ 1 Peter -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: apps built w/ -fstack-protector-all segfault
On Thu, 17 Nov 2005, Peter S. Mazinger wrote: > On Wed, 16 Nov 2005, Richard Henderson wrote: > > > On Wed, Nov 16, 2005 at 10:32:45PM +0100, Peter S. Mazinger wrote: > > > what happens w/ -fstack-protector-all -fstack-protector (in this order) ? > > > do we have (2) or (1) > > > > We have 1. > > > > > so now it does > > > -fstack-protector #define __SSP__ 1 ; #undef __SSP_ALL__ > > > -fstack-protector-all #define __SSP_ALL__ 2 ; #undef __SSP__ > > > > > > and the last wins. > > > > I don't know what you're looking at, but it isn't mainline. > > The defines are not controled this way. > > The defines are exactly like this (only undef is not done, because the > last wins) > > so -fstack-protector -fstack-protector-all will have only __SSP_ALL__ 2 > -fstack-protector-all -fstack-protector will have only __SSP__ 1 > > so in any case the last wins > > -fstack-protector-all (all protection) being superset of -fstack-protector > (random protection) it should also define __SSP__ 1 or maybe better, remove __SSP_ALL__ and define __SSP__ 2 for -all Peter -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
RFC: generalize STARTFILE/ENDFILE_SPEC for linux
Hello!
Would the attached patch be acceptable?
The gcc.c patch part should really go to gcc/config/linux.h, but sadly not
all archs include that file.
for HAVE_ENDFILE_MATH and HAVE_NOSTARTFILE_STATIC another possibility
would be
%{static:%:if-exists-else(crtbeginT.o%s crtbegin.o%s)}
%{ffast-math|funsafe-math-optimizations:%:if-exists(crtfastmath.o%s)}
Thanks, Peter
PS: please CC to me, not on ml.
--
Peter S. MazingerID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
--- gcc-4.1/gcc/config/alpha/elf.h.startend~2005-09-05 15:42:35 +0200
+++ gcc-4.1/gcc/config/alpha/elf.h 2006-01-09 02:12:01 +0100
@@ -392,25 +392,16 @@
before entering `main'. */
#undef STARTFILE_SPEC
-#ifdef HAVE_LD_PIE
-#define STARTFILE_SPEC \
- "%{!shared: %{pg|p:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}\
- crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
-#else
-#define STARTFILE_SPEC \
- "%{!shared: %{pg|p:gcrt1.o%s;:crt1.o%s}}\
- crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
-#endif
+#define STARTFILE_SPEC STARTFILE_PIE_LINUX_SPEC
/* Provide a ENDFILE_SPEC appropriate for ELF. Here we tack on the
magical crtend.o file which provides part of the support for
getting C++ file-scope static object constructed before entering
`main', followed by a normal ELF "finalizer" file, `crtn.o'. */
+#define HAVE_ENDFILE_MATH 1
#undef ENDFILE_SPEC
-#define ENDFILE_SPEC \
- "%{ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
- %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
+#define ENDFILE_SPEC ENDFILE_PIE_LINUX_SPEC
/* We support #pragma. */
#define HANDLE_SYSV_PRAGMA 1
--- gcc-4.1/gcc/config/arm/uclinux-elf.h.startend~ 2005-11-12 21:35:52
+0100
+++ gcc-4.1/gcc/config/arm/uclinux-elf.h2006-01-09 02:12:35 +0100
@@ -44,13 +44,9 @@
provides part of the support for getting C++ file-scope static
object constructed before entering `main'. */
+#define HAVE_NOSTARTFILE_STATIC 1
#undef STARTFILE_SPEC
-#define STARTFILE_SPEC \
- "%{!shared: \
- %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} \
- %{!p:%{profile:gcrt1.o%s} \
-%{!profile:crt1.o%s \
- crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s}"
+#define STARTFILE_SPEC STARTFILE_PIE_LINUX_SPEC
/* Provide a ENDFILE_SPEC appropriate for GNU/Linux. Here we tack on
the GNU/Linux magical crtend.o file (see crtstuff.c) which
@@ -59,8 +55,7 @@
GNU/Linux "finalizer" file, `crtn.o'. */
#undef ENDFILE_SPEC
-#define ENDFILE_SPEC \
- "%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s"
+#define ENDFILE_SPEC ENDFILE_PIE_LINUX_SPEC
#undef CC1_SPEC
#define CC1_SPEC "%{profile:-p}"
--- gcc-4.1/gcc/config/frv/linux.h.startend~2006-01-09 02:18:18 +0100
+++ gcc-4.1/gcc/config/frv/linux.h 2006-01-09 02:18:46 +0100
@@ -28,13 +28,10 @@
"%{!mno-fdpic:-mfdpic}",
#undef STARTFILE_SPEC
-#define STARTFILE_SPEC \
- "%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}} \
- crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+#define STARTFILE_SPEC STARTFILE_PIE_LINUX_SPEC
#undef ENDFILE_SPEC
-#define ENDFILE_SPEC \
- "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
+#define ENDFILE_SPEC ENDFILE_PIE_LINUX_SPEC
#undef LINK_SPEC
#define LINK_SPEC "\
--- gcc-4.1/gcc/config/i386/linux.h.startend~ 2006-01-09 02:22:49 +0100
+++ gcc-4.1/gcc/config/i386/linux.h 2006-01-09 02:23:47 +0100
@@ -122,10 +122,8 @@
%{static:-static}}}"
/* Similar to standard Linux, but adding -ffast-math support. */
-#undef ENDFILE_SPEC
-#define ENDFILE_SPEC \
- "%{ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
- %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
+#define HAVE_ENDFILE_MATH 1
+#undef ENDFILE_SPEC ENDFILE_PIE_LINUX_SPEC
/* A C statement (sans semicolon) to output to the stdio stream
FILE the assembler definition of uninitialized global DECL named
--- gcc-4.1/gcc/config/ia64/linux.h.startend~ 2004-09-08 02:17:14 +0200
+++ gcc-4.1/gcc/config/ia64/linux.h 2006-01-09 02:11:09 +0100
@@ -16,23 +16,15 @@
builtin_define("_LONGLONG");\
} while (0)
-/* Need to override linux.h STARTFILE_SPEC, since it has crtbeginT.o in. */
+#define HAVE_NOSTARTFILE_STATIC 1
#undef STARTFILE_SPEC
-#ifdef HAVE_LD_PIE
-#define STARTFILE_SPEC \
- "%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}\
- crti.o%s %{shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
-#else
-#define STARTFILE_SPEC \
- "%{!shared: %{pg|p|profile:gcrt1.o%s;:crt1.o%s}}\
- crti.o%s %{shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
-#endif
+#define STARTFILE_SPEC STARTFILE_PIE_LINUX_SPEC
/* Similar to standard Linux, but adding -ffast-math support.
Re: RFC: generalize STARTFILE/ENDFILE_SPEC for linux
On Mon, 9 Jan 2006, Jakub Jelinek wrote:
> On Mon, Jan 09, 2006 at 02:38:17PM +0100, Peter S. Mazinger wrote:
> > for HAVE_ENDFILE_MATH and HAVE_NOSTARTFILE_STATIC another possibility
> > would be
> > %{static:%:if-exists-else(crtbeginT.o%s crtbegin.o%s)}
> > %{ffast-math|funsafe-math-optimizations:%:if-exists(crtfastmath.o%s)}
>
> That's IMHO a bad idea, because that means additional runtime overhead.
>
> Jakub
ok, haven't thought of the performance impact, the patch as it is won't
have this problem.
Thanks, Peter
--
Peter S. MazingerID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
PATCH: m68k PIC touchup
Hello!
patch for m68k to handle PIC as the other archs
Please apply, thx, Peter
--
Peter S. MazingerID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
--- gcc-4.0.2/gcc/config/m68k/linux.h.mps 2006-01-08 23:02:06 +0100
+++ gcc-4.0.2/gcc/config/m68k/linux.h 2006-01-08 23:03:02 +0100
@@ -85,6 +85,11 @@
LINUX_TARGET_OS_CPP_BUILTINS(); \
builtin_define_std ("mc68000"); \
builtin_define_std ("mc68020"); \
+ if (flag_pic) \
+ { \
+ builtin_define ("__PIC__"); \
+ builtin_define ("__pic__"); \
+ } \
} \
while (0)
@@ -98,10 +103,10 @@
#undef CPP_SPEC
#if TARGET_DEFAULT & MASK_68881
#define CPP_SPEC \
- "%{fPIC|fpic|fPIE|fpie:-D__PIC__ -D__pic__} %{!msoft-float:-D__HAVE_68881__}
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}"
+ "%{!msoft-float:-D__HAVE_68881__} %{posix:-D_POSIX_SOURCE}
%{pthread:-D_REENTRANT}"
#else
#define CPP_SPEC \
- "%{fPIC|fpic|fPIE|fpie:-D__PIC__ -D__pic__} %{m68881:-D__HAVE_68881__}
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}"
+ "%{m68881:-D__HAVE_68881__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}"
#endif
/* We override the ASM_SPEC from svr4.h because we must pass -m68040 down
-symbolic unsupported
Hello!
Checking the linux configs for different archs only arm has
%{symbolic:-Bsymbolic} for linking.
Is arm out of date, or should the others been updated?
Thanks, Peter
--
Peter S. MazingerID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
ssp check
Hello! The ssp check (gcc_cv_libc_provides_ssp) is glibc centric and the ssp implementation itself assumes that if ssp is provided by libc/ld combo, then the guard is for sure set up in TLS. What would be an acceptable way to provide support for non-glibc/non-TLS? 1. provide 2 configure options, one that omits the above mentioned check and the other that disables ssp in TLS (GUARD_IS_NOT_IN_TLS) the latter being a guard in linux*.h, like -#ifdef TARGET_LIBC_PROVIDES_SSP +#if defined TARGET_LIBC_PROVIDES_SSP && !defined GUARD_IS_NOT_IN_TLS #define TARGET_THREAD_SSP_OFFSET blah #endif 2. replace the features.h grep w/ (or similar) with compiling a dummy test file, get the used ld.so and libc.so from there and do something like (works only for non-cross builds) (nm -D --defined-only ld.so | grep __stack_chk_guard) && (nm -D --defined-only libc.so.x | grep __stack_chk_fail) This would cover the non-glibc version. I have no idea how to check in TLS if __stack_chk_guard is there. Thanks, Peter PS: please CC to me. -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
