* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
[not found] ` <fa.iffnN5wM1UwqtCYhmqLAkGCMC2o@ifi.uio.no>
@ 2006-07-02 17:31 ` Robert Hancock
2006-07-02 17:44 ` H. Peter Anvin
0 siblings, 1 reply; 31+ messages in thread
From: Robert Hancock @ 2006-07-02 17:31 UTC (permalink / raw)
To: Miles Lane; +Cc: Arjan van de Ven, Andrew Morton, LKML
Miles Lane wrote:
> Well, from the web page referenced at the top of this message, you
> can see that they are already aware of these issues:
>
> Cons:
> * It breaks current upstream kernel builds and potentially
> other direct usages of gcc. Kernel is by far the most important use
> case. Upstream should change the default options to build with
> -fno-stack-protector by default.
> * It is not conformant to upstream gcc behaviour.
I don't see why the kernel should have to insert compile flags to
counteract any random non-default compile flags that the system may
decide to insert. I think the way Ubuntu has done this is broken, they
are essentially changing the default settings on the compiler in a way
which breaks the kernel due to needing external libraries.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-02 17:31 ` 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail' Robert Hancock
@ 2006-07-02 17:44 ` H. Peter Anvin
2006-07-02 17:51 ` Arjan van de Ven
0 siblings, 1 reply; 31+ messages in thread
From: H. Peter Anvin @ 2006-07-02 17:44 UTC (permalink / raw)
To: Robert Hancock; +Cc: Miles Lane, Arjan van de Ven, Andrew Morton, LKML
Robert Hancock wrote:
> Miles Lane wrote:
>> Well, from the web page referenced at the top of this message, you
>> can see that they are already aware of these issues:
>>
>> Cons:
>> * It breaks current upstream kernel builds and potentially
>> other direct usages of gcc. Kernel is by far the most important use
>> case. Upstream should change the default options to build with
>> -fno-stack-protector by default.
>> * It is not conformant to upstream gcc behaviour.
>
> I don't see why the kernel should have to insert compile flags to
> counteract any random non-default compile flags that the system may
> decide to insert. I think the way Ubuntu has done this is broken, they
> are essentially changing the default settings on the compiler in a way
> which breaks the kernel due to needing external libraries.
>
There is a good answer to that question, and that is, the kernel is the
special case. It DOES make sense to let the distribution set the
default to whatever they think the end user should use for applications.
The kernel can deal with it easily enough.
-hpa
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-02 17:44 ` H. Peter Anvin
@ 2006-07-02 17:51 ` Arjan van de Ven
2006-07-02 18:01 ` H. Peter Anvin
0 siblings, 1 reply; 31+ messages in thread
From: Arjan van de Ven @ 2006-07-02 17:51 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Robert Hancock, Miles Lane, Andrew Morton, LKML
> There is a good answer to that question, and that is, the kernel is the
> special case. It DOES make sense to let the distribution set the
> default to whatever they think the end user should use for applications.
yeah.. but it's called "CFLAGS environment variable" :-)
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-02 17:51 ` Arjan van de Ven
@ 2006-07-02 18:01 ` H. Peter Anvin
0 siblings, 0 replies; 31+ messages in thread
From: H. Peter Anvin @ 2006-07-02 18:01 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Robert Hancock, Miles Lane, Andrew Morton, LKML
Arjan van de Ven wrote:
>> There is a good answer to that question, and that is, the kernel is the
>> special case. It DOES make sense to let the distribution set the
>> default to whatever they think the end user should use for applications.
>
> yeah.. but it's called "CFLAGS environment variable" :-)
>
Absolutely not. Setting a CFLAGS environment variable has an effect
which is at very best unpredictable when dealing with a great span of
applications. Setting a CC environment variable is actually safer in
many ways, but even that is cantankerous.
-hpa
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-03 13:07 ` Miles Lane
@ 2006-07-03 15:09 ` H. Peter Anvin
0 siblings, 0 replies; 31+ messages in thread
From: H. Peter Anvin @ 2006-07-03 15:09 UTC (permalink / raw)
To: Miles Lane; +Cc: Ingo Molnar, Arjan van de Ven, Andrew Morton, LKML
Miles Lane wrote:
>
> Well, I see that Andrew has accepted (mm5)
> the -fno-stack-protector patch for the Makefile, but klibc remains
> unpatched (scripts/Kbuild.klibc and usr/klibc/arch/i386/MCONFIG).
> Would the right person in this dialog submit those changes to Andrew?
>
The fix is in my private tree, but given that we're in a merge window, I
don't want to push it out right now until I've been able to figure out
why an unrelated change cause make to spew warning messages.
-hpa
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-03 5:17 ` Ingo Molnar
@ 2006-07-03 13:07 ` Miles Lane
2006-07-03 15:09 ` H. Peter Anvin
0 siblings, 1 reply; 31+ messages in thread
From: Miles Lane @ 2006-07-03 13:07 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Arjan van de Ven, Andrew Morton, LKML
On 7/2/06, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Miles Lane <miles.lane@gmail.com> wrote:
>
> > >If Ubuntu patched gcc rather than just putting it in the build
> > >environment... then you should switch to a less braindead distribution
> > >really ;)
>
> > Well, from the web page referenced at the top of this message, you can
> > see that they are already aware of these issues:
> >
> > Cons:
> > * It breaks current upstream kernel builds and potentially
> > other direct usages of gcc. Kernel is by far the most important use
> > case. Upstream should change the default options to build with
> > -fno-stack-protector by default.
> > * It is not conformant to upstream gcc behaviour.
>
> i think the only sane way for a generic distro to introduce an intrusive
> security feature is a 3-phase process:
>
> #1 - introduce the new security option
> #2 - increase use of it gradually, map all the exceptions on the way
> #3 - once exceptions are mapped widely enough, switch the option to
> default-on
>
> this makes the introduction of security seemless/gradual to
> users/developers, without compromising on the end goal of having the
> security feature on by default.
>
> Ubuntu seems to have opted to go to phase #3 directly, which is no doubt
> quite brutal but it's their choice. In any case, whichever methodology
> is used the kernel got flagged as an "exception" and we should help this
> security effort and change the kernel: i.e. lets apply the
> -fno-stack-protector flag to the kernel build.
Well, I see that Andrew has accepted (mm5)
the -fno-stack-protector patch for the Makefile, but klibc remains
unpatched (scripts/Kbuild.klibc and usr/klibc/arch/i386/MCONFIG).
Would the right person in this dialog submit those changes to Andrew?
Many thanks,
Miles
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-02 17:07 ` Miles Lane
2006-07-02 17:32 ` Arjan van de Ven
@ 2006-07-03 5:17 ` Ingo Molnar
2006-07-03 13:07 ` Miles Lane
1 sibling, 1 reply; 31+ messages in thread
From: Ingo Molnar @ 2006-07-03 5:17 UTC (permalink / raw)
To: Miles Lane; +Cc: Arjan van de Ven, Andrew Morton, LKML
* Miles Lane <miles.lane@gmail.com> wrote:
> >If Ubuntu patched gcc rather than just putting it in the build
> >environment... then you should switch to a less braindead distribution
> >really ;)
> Well, from the web page referenced at the top of this message, you can
> see that they are already aware of these issues:
>
> Cons:
> * It breaks current upstream kernel builds and potentially
> other direct usages of gcc. Kernel is by far the most important use
> case. Upstream should change the default options to build with
> -fno-stack-protector by default.
> * It is not conformant to upstream gcc behaviour.
i think the only sane way for a generic distro to introduce an intrusive
security feature is a 3-phase process:
#1 - introduce the new security option
#2 - increase use of it gradually, map all the exceptions on the way
#3 - once exceptions are mapped widely enough, switch the option to
default-on
this makes the introduction of security seemless/gradual to
users/developers, without compromising on the end goal of having the
security feature on by default.
Ubuntu seems to have opted to go to phase #3 directly, which is no doubt
quite brutal but it's their choice. In any case, whichever methodology
is used the kernel got flagged as an "exception" and we should help this
security effort and change the kernel: i.e. lets apply the
-fno-stack-protector flag to the kernel build.
Ingo
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-02 17:50 ` Arjan van de Ven
2006-07-02 17:52 ` Arjan van de Ven
@ 2006-07-02 18:04 ` H. Peter Anvin
1 sibling, 0 replies; 31+ messages in thread
From: H. Peter Anvin @ 2006-07-02 18:04 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Miles Lane, Andrew Morton, LKML
Arjan van de Ven wrote:
>>>
>> Obviously, but at that time we should enable -fno-stack-protector vs
>
> -fno-stack-protector doesn't even exist afaics; simply because gcc has
> this as a positive commandline option only..
You actively have to fight gcc's internals to make a boolean option
positive only, and that's a good thing. The only reason it's possible
at all are as a way to deal with multistate options.
-hpa
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-02 17:50 ` Arjan van de Ven
@ 2006-07-02 17:52 ` Arjan van de Ven
2006-07-02 18:04 ` H. Peter Anvin
1 sibling, 0 replies; 31+ messages in thread
From: Arjan van de Ven @ 2006-07-02 17:52 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Miles Lane, Andrew Morton, LKML
On Sun, 2006-07-02 at 19:50 +0200, Arjan van de Ven wrote:
> On Sun, 2006-07-02 at 10:37 -0700, H. Peter Anvin wrote:
> > Arjan van de Ven wrote:
> > >
> > >> Does this mean that you don't want to see these fno-stack-protector
> > >> patches go into Andrew's tree?
> > >
> > > long term.. no. Because I want to enable stack-protector for the kernel
> > > (I have patches for that; all it needs is a 5 line gcc patch to make it
> > > work) as debug option at least (and if the perf impact isn't too bad,
> > > distros and security sensitive people can enable it always).
> > >
> >
> > Obviously, but at that time we should enable -fno-stack-protector vs
>
> -fno-stack-protector doesn't even exist afaics;
ok it does; I just tested on the wrong machine
sorry
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-02 17:37 ` H. Peter Anvin
@ 2006-07-02 17:50 ` Arjan van de Ven
2006-07-02 17:52 ` Arjan van de Ven
2006-07-02 18:04 ` H. Peter Anvin
0 siblings, 2 replies; 31+ messages in thread
From: Arjan van de Ven @ 2006-07-02 17:50 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Miles Lane, Andrew Morton, LKML
On Sun, 2006-07-02 at 10:37 -0700, H. Peter Anvin wrote:
> Arjan van de Ven wrote:
> >
> >> Does this mean that you don't want to see these fno-stack-protector
> >> patches go into Andrew's tree?
> >
> > long term.. no. Because I want to enable stack-protector for the kernel
> > (I have patches for that; all it needs is a 5 line gcc patch to make it
> > work) as debug option at least (and if the perf impact isn't too bad,
> > distros and security sensitive people can enable it always).
> >
>
> Obviously, but at that time we should enable -fno-stack-protector vs
-fno-stack-protector doesn't even exist afaics; simply because gcc has
this as a positive commandline option only..
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-02 17:32 ` Arjan van de Ven
@ 2006-07-02 17:37 ` H. Peter Anvin
2006-07-02 17:50 ` Arjan van de Ven
0 siblings, 1 reply; 31+ messages in thread
From: H. Peter Anvin @ 2006-07-02 17:37 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Miles Lane, Andrew Morton, LKML
Arjan van de Ven wrote:
>
>> Does this mean that you don't want to see these fno-stack-protector
>> patches go into Andrew's tree?
>
> long term.. no. Because I want to enable stack-protector for the kernel
> (I have patches for that; all it needs is a 5 line gcc patch to make it
> work) as debug option at least (and if the perf impact isn't too bad,
> distros and security sensitive people can enable it always).
>
Obviously, but at that time we should enable -fno-stack-protector vs
-fstack-protector as appropriate.
-hpa
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-02 17:07 ` Miles Lane
@ 2006-07-02 17:32 ` Arjan van de Ven
2006-07-02 17:37 ` H. Peter Anvin
2006-07-03 5:17 ` Ingo Molnar
1 sibling, 1 reply; 31+ messages in thread
From: Arjan van de Ven @ 2006-07-02 17:32 UTC (permalink / raw)
To: Miles Lane; +Cc: Andrew Morton, LKML
> Does this mean that you don't want to see these fno-stack-protector
> patches go into Andrew's tree?
long term.. no. Because I want to enable stack-protector for the kernel
(I have patches for that; all it needs is a 5 line gcc patch to make it
work) as debug option at least (and if the perf impact isn't too bad,
distros and security sensitive people can enable it always).
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-02 7:42 ` Arjan van de Ven
@ 2006-07-02 17:07 ` Miles Lane
2006-07-02 17:32 ` Arjan van de Ven
2006-07-03 5:17 ` Ingo Molnar
0 siblings, 2 replies; 31+ messages in thread
From: Miles Lane @ 2006-07-02 17:07 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Andrew Morton, LKML
On 7/2/06, Arjan van de Ven <arjan@infradead.org> wrote:
>
> > https://wiki.ubuntu.com/GccSsp
> >
> > It appears that Ubuntu's Edgy Eft (the development tree) now contains
> > "Stack Smashing Protection" enabled by default. I found a web page
> > that states that -fno-stack-protector can be used to disable this
> > functionality. Interestingly, another web page stated that SSP has
> > been enabled in Redhat compilers for a long time and is now also
> > enabled in Debian SID. Perhaps -fno-stack-protector should be added
> > to the kernel build be default?
>
>
> gcc 4.1 and later have this feature yes.
> HOWEVER the gcc people were not stupid, they did not force this on
> people, they require you to put -fstack-protector on the commandline.
> Debian and RH/Fedora do this.
> If Ubuntu patched gcc rather than just putting it in the build
> environment... then you should switch to a less braindead distribution
> really ;)
> or at least ask them to fix this.
Well, from the web page referenced at the top of this message, you
can see that they are already aware of these issues:
Cons:
* It breaks current upstream kernel builds and potentially
other direct usages of gcc. Kernel is by far the most important use
case. Upstream should change the default options to build with
-fno-stack-protector by default.
* It is not conformant to upstream gcc behaviour.
You can reach the key people who are working on this for Ubuntu here:
Matt Zimmerman -- mdz at ubuntu dot com
Martin Pitt -- martin.pitt at ubuntu dot com
Perhaps you can convince them to back out this functional change?
Does this mean that you don't want to see these fno-stack-protector
patches go into Andrew's tree?
Miles
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-01 22:37 ` Miles Lane
2006-07-01 22:56 ` Miles Lane
@ 2006-07-02 7:42 ` Arjan van de Ven
2006-07-02 17:07 ` Miles Lane
1 sibling, 1 reply; 31+ messages in thread
From: Arjan van de Ven @ 2006-07-02 7:42 UTC (permalink / raw)
To: Miles Lane; +Cc: Andrew Morton, LKML
> https://wiki.ubuntu.com/GccSsp
>
> It appears that Ubuntu's Edgy Eft (the development tree) now contains
> "Stack Smashing Protection" enabled by default. I found a web page
> that states that -fno-stack-protector can be used to disable this
> functionality. Interestingly, another web page stated that SSP has
> been enabled in Redhat compilers for a long time and is now also
> enabled in Debian SID. Perhaps -fno-stack-protector should be added
> to the kernel build be default?
gcc 4.1 and later have this feature yes.
HOWEVER the gcc people were not stupid, they did not force this on
people, they require you to put -fstack-protector on the commandline.
Debian and RH/Fedora do this.
If Ubuntu patched gcc rather than just putting it in the build
environment... then you should switch to a less braindead distribution
really ;)
or at least ask them to fix this.
Greetings,
Arjan van de Ven
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-02 4:52 ` H. Peter Anvin
@ 2006-07-02 6:12 ` Miles Lane
0 siblings, 0 replies; 31+ messages in thread
From: Miles Lane @ 2006-07-02 6:12 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Sam Ravnborg, Arjan van de Ven, Andrew Morton, LKML
On 7/1/06, H. Peter Anvin <hpa@zytor.com> wrote:
> Miles Lane wrote:
> >
> > CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
> > $(call cc-option, -fno-stack-protector, ) -fno-common
> > in Makefile.
> >
> > Trying to compile, I get:
> >
> > include/asm/system.h: In function '__set_64bit_var':
> > include/asm/system.h:209: warning: dereferencing type-punned pointer
> > will break strict-aliasing rules
>
> That's because the kernel CFLAGS need to include -fno-strict-aliasing.
Okay, problem solved for me. Can we get these patches in to the mm tree?
Thanks,
Miles
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-02 4:05 ` Miles Lane
@ 2006-07-02 4:52 ` H. Peter Anvin
2006-07-02 6:12 ` Miles Lane
0 siblings, 1 reply; 31+ messages in thread
From: H. Peter Anvin @ 2006-07-02 4:52 UTC (permalink / raw)
To: Miles Lane; +Cc: Sam Ravnborg, Arjan van de Ven, Andrew Morton, LKML
Miles Lane wrote:
>
> CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
> $(call cc-option, -fno-stack-protector, ) -fno-common
> in Makefile.
>
> Trying to compile, I get:
>
> include/asm/system.h: In function '__set_64bit_var':
> include/asm/system.h:209: warning: dereferencing type-punned pointer
> will break strict-aliasing rules
That's because the kernel CFLAGS need to include -fno-strict-aliasing.
-hpa
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
[not found] ` <fa.LW8cO+QP5MhBZ9HST2AOy+N/e6o@ifi.uio.no>
@ 2006-07-02 4:26 ` Robert Hancock
0 siblings, 0 replies; 31+ messages in thread
From: Robert Hancock @ 2006-07-02 4:26 UTC (permalink / raw)
To: Miles Lane
Cc: H. Peter Anvin, Sam Ravnborg, Arjan van de Ven, Andrew Morton, LKML
Miles Lane wrote:
> Trying to compile, I get:
>
> include/asm/system.h: In function '__set_64bit_var':
> include/asm/system.h:209: warning: dereferencing type-punned pointer
> will break strict-aliasing rules
Sounds like you're still getting a bunch of bad compile flags passed in.
You likely need to remove the CFLAGS from your shell environment or
something so that the kernel build stops inheriting them all.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-02 3:03 ` H. Peter Anvin
@ 2006-07-02 4:05 ` Miles Lane
2006-07-02 4:52 ` H. Peter Anvin
0 siblings, 1 reply; 31+ messages in thread
From: Miles Lane @ 2006-07-02 4:05 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Sam Ravnborg, Arjan van de Ven, Andrew Morton, LKML
On 7/1/06, H. Peter Anvin <hpa@zytor.com> wrote:
> Sam Ravnborg wrote:
> >
> >> -KLIBCREQFLAGS :=
> >> +KLIBCREQFLAGS := $(call cc_option, -fno-stack-protector, )
> >
> > This needs to be $(call cc-option, ...)
> > '-' not '_'.
> >
>
> *plonk* OK... I feel dumb now :)
>
> Miles: could you try this out?
>
> >> +++ b/usr/klibc/arch/arm/MCONFIG
> >> @@ -12,7 +12,7 @@ CPU_TUNE := strongarm
> >>
> >> KLIBCOPTFLAGS = -Os -march=$(CPU_ARCH) -mtune=$(CPU_TUNE)
> >> KLIBCBITSIZE = 32
> >> -KLIBCREQFLAGS = -fno-exceptions
> >> +KLIBCREQFLAGS += -fno-exceptions
> >
> > This should be fixed for KLIBCOPTFLAGS also. Unrelated to this issue.
> >
>
> *Nod.*
I gave it my best shot, but my build is still unhappy.
I set:
KLIBCREQFLAGS := $(call cc-option, -fno-stack-protector, )
in scripts/Kbuild.klibc.
KLIBCOPTFLAGS = -march=i386 -Os -g -fomit-frame-pointer
$(gcc_align_option) $(call cc-option, -fno-stack-protector, )
in usr/klibc/arch/i386/MCONFIG
CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
$(call cc-option, -fno-stack-protector, ) -fno-common
in Makefile.
Trying to compile, I get:
include/asm/system.h: In function '__set_64bit_var':
include/asm/system.h:209: warning: dereferencing type-punned pointer
will break strict-aliasing rules
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-02 3:01 ` Sam Ravnborg
@ 2006-07-02 3:03 ` H. Peter Anvin
2006-07-02 4:05 ` Miles Lane
0 siblings, 1 reply; 31+ messages in thread
From: H. Peter Anvin @ 2006-07-02 3:03 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Miles Lane, Arjan van de Ven, Andrew Morton, LKML
Sam Ravnborg wrote:
>
>> -KLIBCREQFLAGS :=
>> +KLIBCREQFLAGS := $(call cc_option, -fno-stack-protector, )
>
> This needs to be $(call cc-option, ...)
> '-' not '_'.
>
*plonk* OK... I feel dumb now :)
Miles: could you try this out?
>> +++ b/usr/klibc/arch/arm/MCONFIG
>> @@ -12,7 +12,7 @@ CPU_TUNE := strongarm
>>
>> KLIBCOPTFLAGS = -Os -march=$(CPU_ARCH) -mtune=$(CPU_TUNE)
>> KLIBCBITSIZE = 32
>> -KLIBCREQFLAGS = -fno-exceptions
>> +KLIBCREQFLAGS += -fno-exceptions
>
> This should be fixed for KLIBCOPTFLAGS also. Unrelated to this issue.
>
*Nod.*
-hpa
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-01 23:35 ` H. Peter Anvin
@ 2006-07-02 3:01 ` Sam Ravnborg
2006-07-02 3:03 ` H. Peter Anvin
0 siblings, 1 reply; 31+ messages in thread
From: Sam Ravnborg @ 2006-07-02 3:01 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Miles Lane, Arjan van de Ven, Andrew Morton, LKML
On Sat, Jul 01, 2006 at 04:35:32PM -0700, H. Peter Anvin wrote:
> Sam Ravnborg wrote:
> >
> >For klibc you need to patch scripts/Kbuild.klibc
> >
> >Appending it to KLIBCWARNFLAGS seems the right place.
> >
> >Do you know from what gcc version we can start using -fno-stack-protector?
> >
>
> Here is a patch for klibc. Miles, could you try it out and see if it
> does what you need?
>
> -hpa
>
> -KLIBCREQFLAGS :=
> +KLIBCREQFLAGS := $(call cc_option, -fno-stack-protector, )
This needs to be $(call cc-option, ...)
'-' not '_'.
> +++ b/usr/klibc/arch/arm/MCONFIG
> @@ -12,7 +12,7 @@ CPU_TUNE := strongarm
>
> KLIBCOPTFLAGS = -Os -march=$(CPU_ARCH) -mtune=$(CPU_TUNE)
> KLIBCBITSIZE = 32
> -KLIBCREQFLAGS = -fno-exceptions
> +KLIBCREQFLAGS += -fno-exceptions
This should be fixed for KLIBCOPTFLAGS also. Unrelated to this issue.
Sam
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-01 23:06 ` Sam Ravnborg
2006-07-01 23:11 ` H. Peter Anvin
2006-07-01 23:34 ` Miles Lane
@ 2006-07-01 23:35 ` H. Peter Anvin
2006-07-02 3:01 ` Sam Ravnborg
2 siblings, 1 reply; 31+ messages in thread
From: H. Peter Anvin @ 2006-07-01 23:35 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Miles Lane, Arjan van de Ven, Andrew Morton, LKML
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
Sam Ravnborg wrote:
>
> For klibc you need to patch scripts/Kbuild.klibc
>
> Appending it to KLIBCWARNFLAGS seems the right place.
>
> Do you know from what gcc version we can start using -fno-stack-protector?
>
Here is a patch for klibc. Miles, could you try it out and see if it
does what you need?
-hpa
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 967 bytes --]
diff --git a/scripts/Kbuild.klibc b/scripts/Kbuild.klibc
index ac0439e..d30ada2 100644
--- a/scripts/Kbuild.klibc
+++ b/scripts/Kbuild.klibc
@@ -48,7 +48,7 @@ include $(srctree)/scripts/Kbuild.includ
# Defines used when compiling early userspace (klibc programs)
# ---------------------------------------------------------------------------
-KLIBCREQFLAGS :=
+KLIBCREQFLAGS := $(call cc_option, -fno-stack-protector, )
KLIBCARCHREQFLAGS :=
KLIBCOPTFLAGS :=
KLIBCWARNFLAGS := -W -Wall -Wno-sign-compare -Wno-unused-parameter
diff --git a/usr/klibc/arch/arm/MCONFIG b/usr/klibc/arch/arm/MCONFIG
index 0023eee..fa3ada2 100644
--- a/usr/klibc/arch/arm/MCONFIG
+++ b/usr/klibc/arch/arm/MCONFIG
@@ -12,7 +12,7 @@ CPU_TUNE := strongarm
KLIBCOPTFLAGS = -Os -march=$(CPU_ARCH) -mtune=$(CPU_TUNE)
KLIBCBITSIZE = 32
-KLIBCREQFLAGS = -fno-exceptions
+KLIBCREQFLAGS += -fno-exceptions
KLIBCSTRIPFLAGS += -R .ARM.exidx
ifeq ($(CONFIG_KLIBC_THUMB),y)
^ permalink raw reply related [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-01 23:06 ` Sam Ravnborg
2006-07-01 23:11 ` H. Peter Anvin
@ 2006-07-01 23:34 ` Miles Lane
2006-07-01 23:35 ` H. Peter Anvin
2 siblings, 0 replies; 31+ messages in thread
From: Miles Lane @ 2006-07-01 23:34 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Arjan van de Ven, Andrew Morton, LKML, H. Peter Anvin
On 7/1/06, Sam Ravnborg <sam@ravnborg.org> wrote:
> >> > > >
> > >> > > > KLIBCLD usr/klibc/libc.so
> > >> > > > usr/klibc/execl.o: In function `execl':
> ...
> >
> > >https://wiki.ubuntu.com/GccSsp
> > >
> > >It appears that Ubuntu's Edgy Eft (the development tree) now contains
> > >"Stack Smashing Protection" enabled by default. I found a web page
> > >that states that -fno-stack-protector can be used to disable this
> > >functionality. Interestingly, another web page stated that SSP has
> > >been enabled in Redhat compilers for a long time and is now also
> > >enabled in Debian SID. Perhaps -fno-stack-protector should be added
> > >to the kernel build be default?
> >
> > Darn it. I don't seem to know how to get -fno-stack-protector to
> > work. I ran:
> > export CFLAGS=-fno-stack-protector
> > make mrproper
> > cp ../.config .
> > make oldconfig
> > CFLAGS=-fno-stack-protector make all install modules modules_install
> >
> > But I am still getting the errors. Anyone know what I am doing wrong?
>
> For klibc you need to patch scripts/Kbuild.klibc
>
> Appending it to KLIBCWARNFLAGS seems the right place.
>
> Do you know from what gcc version we can start using -fno-stack-protector?
This fixed is for me. Andrew, would this be appropriate to merge into
your tree?
--- scripts/Kbuild.klibc.old 2006-07-01 16:32:55.000000000 -0700
+++ scripts/Kbuild.klibc 2006-07-01 16:28:59.000000000 -0700
@@ -51,7 +51,7 @@
KLIBCREQFLAGS :=
KLIBCARCHREQFLAGS :=
KLIBCOPTFLAGS :=
-KLIBCWARNFLAGS := -W -Wall -Wno-sign-compare -Wno-unused-parameter
+KLIBCWARNFLAGS := -W -Wall -Wno-sign-compare -Wno-unused-parameter
-fno-stack-protector
KLIBCSHAREDFLAGS :=
KLIBCBITSIZE :=
KLIBCLDFLAGS :=
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-01 23:11 ` H. Peter Anvin
@ 2006-07-01 23:26 ` H. Peter Anvin
0 siblings, 0 replies; 31+ messages in thread
From: H. Peter Anvin @ 2006-07-01 23:26 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Sam Ravnborg, Miles Lane, Arjan van de Ven, Andrew Morton, LKML
H. Peter Anvin wrote:
> Sam Ravnborg wrote:
>>
>> For klibc you need to patch scripts/Kbuild.klibc
>>
>> Appending it to KLIBCWARNFLAGS seems the right place.
>
> KLIBCREQFLAGS, rather.
>
>> Do you know from what gcc version we can start using
>> -fno-stack-protector?
>
> Isn't there a macro to test if gcc supports a specific option already?
>
> Either way, I can also add __stack_chk_fail() as an alias for abort(),
> for people who actually want the feature.
>
I looked at it again, and it looks like gcc depends on the TLS ABI in
order to pick the value of the cookie. That makes it a potentially lot
more cantankerous option; I would like to be able to support stack-smash
checking in klibc, but if it means implementing TLS on all
architectures, then that would really defeat the purpose (and we should
add -fno-stack-protector to KLIBCREQFLAGS.)
Arjan: I see a few stack-protector-related have your name on it, do you
have any details on implementation constraints for this across
architectures?
-hpa
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-01 23:06 ` Sam Ravnborg
@ 2006-07-01 23:11 ` H. Peter Anvin
2006-07-01 23:26 ` H. Peter Anvin
2006-07-01 23:34 ` Miles Lane
2006-07-01 23:35 ` H. Peter Anvin
2 siblings, 1 reply; 31+ messages in thread
From: H. Peter Anvin @ 2006-07-01 23:11 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Miles Lane, Arjan van de Ven, Andrew Morton, LKML
Sam Ravnborg wrote:
>
> For klibc you need to patch scripts/Kbuild.klibc
>
> Appending it to KLIBCWARNFLAGS seems the right place.
KLIBCREQFLAGS, rather.
> Do you know from what gcc version we can start using -fno-stack-protector?
Isn't there a macro to test if gcc supports a specific option already?
Either way, I can also add __stack_chk_fail() as an alias for abort(),
for people who actually want the feature.
-hpa
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-01 22:56 ` Miles Lane
@ 2006-07-01 23:06 ` Sam Ravnborg
2006-07-01 23:11 ` H. Peter Anvin
` (2 more replies)
0 siblings, 3 replies; 31+ messages in thread
From: Sam Ravnborg @ 2006-07-01 23:06 UTC (permalink / raw)
To: Miles Lane; +Cc: Arjan van de Ven, Andrew Morton, LKML, H. Peter Anvin
>> > > >
> >> > > > KLIBCLD usr/klibc/libc.so
> >> > > > usr/klibc/execl.o: In function `execl':
...
>
> >https://wiki.ubuntu.com/GccSsp
> >
> >It appears that Ubuntu's Edgy Eft (the development tree) now contains
> >"Stack Smashing Protection" enabled by default. I found a web page
> >that states that -fno-stack-protector can be used to disable this
> >functionality. Interestingly, another web page stated that SSP has
> >been enabled in Redhat compilers for a long time and is now also
> >enabled in Debian SID. Perhaps -fno-stack-protector should be added
> >to the kernel build be default?
>
> Darn it. I don't seem to know how to get -fno-stack-protector to
> work. I ran:
> export CFLAGS=-fno-stack-protector
> make mrproper
> cp ../.config .
> make oldconfig
> CFLAGS=-fno-stack-protector make all install modules modules_install
>
> But I am still getting the errors. Anyone know what I am doing wrong?
For klibc you need to patch scripts/Kbuild.klibc
Appending it to KLIBCWARNFLAGS seems the right place.
Do you know from what gcc version we can start using -fno-stack-protector?
Sam
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-01 22:37 ` Miles Lane
@ 2006-07-01 22:56 ` Miles Lane
2006-07-01 23:06 ` Sam Ravnborg
2006-07-02 7:42 ` Arjan van de Ven
1 sibling, 1 reply; 31+ messages in thread
From: Miles Lane @ 2006-07-01 22:56 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Andrew Morton, LKML
On 7/1/06, Miles Lane <miles.lane@gmail.com> wrote:
> On 7/1/06, Arjan van de Ven <arjan@infradead.org> wrote:
> > On Sat, 2006-07-01 at 14:25 -0700, Miles Lane wrote:
> > > On 7/1/06, Arjan van de Ven <arjan@infradead.org> wrote:
> > > > On Sat, 2006-07-01 at 14:09 -0700, Miles Lane wrote:
> > > > > I am getting this:
> > > > >
> > > > > KLIBCLD usr/klibc/libc.so
> > > > > usr/klibc/execl.o: In function `execl':
> > > > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > > > usr/klibc/execle.o: In function `execle':
> > > > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > > > usr/klibc/execvpe.o: In function `execvpe':
> > > > > usr/klibc/execvpe.c:75: undefined reference to `__stack_chk_fail'
> > > > > usr/klibc/execlp.o: In function `execlp':
> > > > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > > > usr/klibc/execlpe.o: In function `execlpe':
> > > > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > > > usr/klibc/vfprintf.o:usr/klibc/vfprintf.c:26: more undefined
> > > > > references to `__stack_chk_fail' follow
> > > > > make[2]: *** [usr/klibc/libc.so] Error 1
> > > > >
> > > > > But I've searched all the .h and .c files in the tree and found no
> > > > > reference to __stack_chk_fail. I am running Ubuntu's Edgy Eft (the
> > > > > latest development tree).
> > > >
> > > > somehow you're getting -fstack-protector added to your CFLAGs.. which
> > > > won't do you any good unless you link to glibc or another library that
> > > > implements the user side of the feature...
> > >
> > > The only reference to -fstack-protector in my linux kernel tree is here:
> >
> >
> > try looking at your CFLAGS environment variable.. that may get
> > inherited ;)
>
> https://wiki.ubuntu.com/GccSsp
>
> It appears that Ubuntu's Edgy Eft (the development tree) now contains
> "Stack Smashing Protection" enabled by default. I found a web page
> that states that -fno-stack-protector can be used to disable this
> functionality. Interestingly, another web page stated that SSP has
> been enabled in Redhat compilers for a long time and is now also
> enabled in Debian SID. Perhaps -fno-stack-protector should be added
> to the kernel build be default?
Darn it. I don't seem to know how to get -fno-stack-protector to
work. I ran:
export CFLAGS=-fno-stack-protector
make mrproper
cp ../.config .
make oldconfig
CFLAGS=-fno-stack-protector make all install modules modules_install
But I am still getting the errors. Anyone know what I am doing wrong?
Thanks,
Miles
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-01 21:29 ` Arjan van de Ven
@ 2006-07-01 22:37 ` Miles Lane
2006-07-01 22:56 ` Miles Lane
2006-07-02 7:42 ` Arjan van de Ven
0 siblings, 2 replies; 31+ messages in thread
From: Miles Lane @ 2006-07-01 22:37 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Andrew Morton, LKML
On 7/1/06, Arjan van de Ven <arjan@infradead.org> wrote:
> On Sat, 2006-07-01 at 14:25 -0700, Miles Lane wrote:
> > On 7/1/06, Arjan van de Ven <arjan@infradead.org> wrote:
> > > On Sat, 2006-07-01 at 14:09 -0700, Miles Lane wrote:
> > > > I am getting this:
> > > >
> > > > KLIBCLD usr/klibc/libc.so
> > > > usr/klibc/execl.o: In function `execl':
> > > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > > usr/klibc/execle.o: In function `execle':
> > > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > > usr/klibc/execvpe.o: In function `execvpe':
> > > > usr/klibc/execvpe.c:75: undefined reference to `__stack_chk_fail'
> > > > usr/klibc/execlp.o: In function `execlp':
> > > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > > usr/klibc/execlpe.o: In function `execlpe':
> > > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > > usr/klibc/vfprintf.o:usr/klibc/vfprintf.c:26: more undefined
> > > > references to `__stack_chk_fail' follow
> > > > make[2]: *** [usr/klibc/libc.so] Error 1
> > > >
> > > > But I've searched all the .h and .c files in the tree and found no
> > > > reference to __stack_chk_fail. I am running Ubuntu's Edgy Eft (the
> > > > latest development tree).
> > >
> > > somehow you're getting -fstack-protector added to your CFLAGs.. which
> > > won't do you any good unless you link to glibc or another library that
> > > implements the user side of the feature...
> >
> > The only reference to -fstack-protector in my linux kernel tree is here:
>
>
> try looking at your CFLAGS environment variable.. that may get
> inherited ;)
https://wiki.ubuntu.com/GccSsp
It appears that Ubuntu's Edgy Eft (the development tree) now contains
"Stack Smashing Protection" enabled by default. I found a web page
that states that -fno-stack-protector can be used to disable this
functionality. Interestingly, another web page stated that SSP has
been enabled in Redhat compilers for a long time and is now also
enabled in Debian SID. Perhaps -fno-stack-protector should be added
to the kernel build be default?
Thanks,
Miles
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-01 21:25 ` Miles Lane
@ 2006-07-01 21:29 ` Arjan van de Ven
2006-07-01 22:37 ` Miles Lane
0 siblings, 1 reply; 31+ messages in thread
From: Arjan van de Ven @ 2006-07-01 21:29 UTC (permalink / raw)
To: Miles Lane; +Cc: Andrew Morton, LKML
On Sat, 2006-07-01 at 14:25 -0700, Miles Lane wrote:
> On 7/1/06, Arjan van de Ven <arjan@infradead.org> wrote:
> > On Sat, 2006-07-01 at 14:09 -0700, Miles Lane wrote:
> > > I am getting this:
> > >
> > > KLIBCLD usr/klibc/libc.so
> > > usr/klibc/execl.o: In function `execl':
> > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > usr/klibc/execle.o: In function `execle':
> > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > usr/klibc/execvpe.o: In function `execvpe':
> > > usr/klibc/execvpe.c:75: undefined reference to `__stack_chk_fail'
> > > usr/klibc/execlp.o: In function `execlp':
> > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > usr/klibc/execlpe.o: In function `execlpe':
> > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > usr/klibc/vfprintf.o:usr/klibc/vfprintf.c:26: more undefined
> > > references to `__stack_chk_fail' follow
> > > make[2]: *** [usr/klibc/libc.so] Error 1
> > >
> > > But I've searched all the .h and .c files in the tree and found no
> > > reference to __stack_chk_fail. I am running Ubuntu's Edgy Eft (the
> > > latest development tree).
> >
> > somehow you're getting -fstack-protector added to your CFLAGs.. which
> > won't do you any good unless you link to glibc or another library that
> > implements the user side of the feature...
>
> The only reference to -fstack-protector in my linux kernel tree is here:
try looking at your CFLAGS environment variable.. that may get
inherited ;)
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-01 21:17 ` Arjan van de Ven
@ 2006-07-01 21:25 ` Miles Lane
2006-07-01 21:29 ` Arjan van de Ven
0 siblings, 1 reply; 31+ messages in thread
From: Miles Lane @ 2006-07-01 21:25 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Andrew Morton, LKML
On 7/1/06, Arjan van de Ven <arjan@infradead.org> wrote:
> On Sat, 2006-07-01 at 14:09 -0700, Miles Lane wrote:
> > I am getting this:
> >
> > KLIBCLD usr/klibc/libc.so
> > usr/klibc/execl.o: In function `execl':
> > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > usr/klibc/execle.o: In function `execle':
> > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > usr/klibc/execvpe.o: In function `execvpe':
> > usr/klibc/execvpe.c:75: undefined reference to `__stack_chk_fail'
> > usr/klibc/execlp.o: In function `execlp':
> > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > usr/klibc/execlpe.o: In function `execlpe':
> > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > usr/klibc/vfprintf.o:usr/klibc/vfprintf.c:26: more undefined
> > references to `__stack_chk_fail' follow
> > make[2]: *** [usr/klibc/libc.so] Error 1
> >
> > But I've searched all the .h and .c files in the tree and found no
> > reference to __stack_chk_fail. I am running Ubuntu's Edgy Eft (the
> > latest development tree).
>
> somehow you're getting -fstack-protector added to your CFLAGs.. which
> won't do you any good unless you link to glibc or another library that
> implements the user side of the feature...
The only reference to -fstack-protector in my linux kernel tree is here:
arch/i386/kernel/asm-offsets.s
.file "asm-offsets.c"
# GNU C version 4.1.2 20060613 (prerelease) (Ubuntu 4.1.1-2ubuntu5)
(i486-linux-gnu)
# compiled by GNU C version 4.1.2 20060613 (prerelease) (Ubuntu
4.1.1-2ubuntu5).
# GGC heuristics: --param ggc-min-expand=96 --param ggc-min-heapsize=125021
# options passed: -nostdinc -Iinclude -Iinclude/asm-i386/mach-default
# -D__KERNEL__ -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(asm_offsets)
# -DKBUILD_MODNAME=KBUILD_STR(asm_offsets) -isystem -include -MD -m32
# -msoft-float -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium4
# -mregparm=3 -auxbase-strip -Os -Wall -Wundef -Wstrict-prototypes
# -Wno-trigraphs -Wdeclaration-after-statement -Wno-pointer-sign
# -fno-strict-aliasing -fno-common -fno-omit-frame-pointer
# -fno-optimize-sibling-calls -fasynchronous-unwind-tables -ffreestanding
# -fverbose-asm
# options enabled: -falign-loops -fargument-alias
# -fasynchronous-unwind-tables -fbranch-count-reg -fcaller-saves
# -fcprop-registers -fcrossjumping -fcse-follow-jumps -fcse-skip-blocks
# -fdefer-pop -fdelete-null-pointer-checks -fearly-inlining
# -feliminate-unused-debug-types -fexpensive-optimizations -ffunction-cse
# -fgcse -fgcse-lm -fguess-branch-probability -fident -fif-conversion
# -fif-conversion2 -finline-functions -finline-functions-called-once
# -fipa-pure-const -fipa-reference -fipa-type-escape -fivopts
# -fkeep-static-consts -fleading-underscore -floop-optimize
# -floop-optimize2 -fmath-errno -fmerge-constants -foptimize-register-move
# -fpcc-struct-return -fpeephole -fpeephole2 -fregmove -freorder-functions
# -frerun-cse-after-loop -frerun-loop-opt -fsched-interblock -fsched-spec
# -fsched-stalled-insns-dep -fshow-column -fsplit-ivs-in-unroller
# -fstack-protector -fstrength-reduce -fthread-jumps -ftrapping-math
# -ftree-ccp -ftree-copy-prop -ftree-copyrename -ftree-dce
# -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im
# -ftree-loop-ivcanon -ftree-loop-optimize -ftree-lrs -ftree-salias
# -ftree-sink -ftree-sra -ftree-store-ccp -ftree-store-copy-prop -ftree-ter
# -ftree-vect-loop-version -ftree-vrp -funit-at-a-time -funwind-tables
# -fverbose-asm -fzero-initialized-in-bss -m32 -m96bit-long-double
# -malign-stringops -mieee-fp -mno-fancy-math-387 -mno-red-zone -mpush-args
# -mtls-direct-seg-refs
# Compiler executable checksum: 08eb10034110f95d4c3c06297525c871
.text
.globl foo
.type foo, @function
foo:
.LFB517:
pushl %ebp #
.LCFI0:
movl %esp, %ebp #,
.LCFI1:
#APP
->SIGCONTEXT_eax $44 offsetof(struct sigcontext, eax) #
->SIGCONTEXT_ebx $32 offsetof(struct sigcontext, ebx) #
->SIGCONTEXT_ecx $40 offsetof(struct sigcontext, ecx) #
->SIGCONTEXT_edx $36 offsetof(struct sigcontext, edx) #
->SIGCONTEXT_esi $20 offsetof(struct sigcontext, esi) #
->SIGCONTEXT_edi $16 offsetof(struct sigcontext, edi) #
->SIGCONTEXT_ebp $24 offsetof(struct sigcontext, ebp) #
->SIGCONTEXT_esp $28 offsetof(struct sigcontext, esp) #
->SIGCONTEXT_eip $56 offsetof(struct sigcontext, eip) #
->
->CPUINFO_x86 $0 offsetof(struct cpuinfo_x86, x86) #
->CPUINFO_x86_vendor $1 offsetof(struct cpuinfo_x86, x86_vendor) #
->CPUINFO_x86_model $2 offsetof(struct cpuinfo_x86, x86_model) #
->CPUINFO_x86_mask $3 offsetof(struct cpuinfo_x86, x86_mask) #
->CPUINFO_hard_math $6 offsetof(struct cpuinfo_x86, hard_math) #
->CPUINFO_cpuid_level $8 offsetof(struct cpuinfo_x86, cpuid_level) #
->CPUINFO_x86_capability $12 offsetof(struct cpuinfo_x86,
x86_capability) #
->CPUINFO_x86_vendor_id $40 offsetof(struct cpuinfo_x86, x86_vendor_id) #
->
->TI_task $0 offsetof(struct thread_info, task) #
->TI_exec_domain $4 offsetof(struct thread_info, exec_domain) #
->TI_flags $8 offsetof(struct thread_info, flags) #
->TI_status $12 offsetof(struct thread_info, status) #
->TI_cpu $16 offsetof(struct thread_info, cpu) #
->TI_preempt_count $20 offsetof(struct thread_info, preempt_count) #
->TI_addr_limit $24 offsetof(struct thread_info, addr_limit) #
->TI_restart_block $32 offsetof(struct thread_info, restart_block) #
->TI_sysenter_return $28 offsetof(struct thread_info, sysenter_return) #
->
->EXEC_DOMAIN_handler $4 offsetof(struct exec_domain, handler) #
->RT_SIGFRAME_sigcontext $164 offsetof(struct rt_sigframe,
uc.uc_mcontext) #
->
->pbe_address $0 offsetof(struct pbe, address) #
->pbe_orig_address $4 offsetof(struct pbe, orig_address) #
->pbe_next $8 offsetof(struct pbe, next) #
->TSS_sysenter_esp0 $-8700 offsetof(struct tss_struct, esp0) -
sizeof(struct tss_struct) #
->PAGE_SIZE_asm $4096 PAGE_SIZE #
->VDSO_PRELINK $-8192 VDSO_PRELINK #
->crypto_tfm_ctx_offset $48 offsetof(struct crypto_tfm, __crt_ctx) #
#NO_APP
popl %ebp #
ret
.LFE517:
.size foo, .-foo
.section .eh_frame,"a",@progbits
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0x0
.byte 0x1
.string ""
.uleb128 0x1
.sleb128 -4
.byte 0x8
.byte 0xc
.uleb128 0x4
.uleb128 0x4
.byte 0x88
.uleb128 0x1
.align 4
.LECIE1:
.LSFDE1:
.long .LEFDE1-.LASFDE1
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB517
.long .LFE517-.LFB517
.byte 0x4
.long .LCFI0-.LFB517
.byte 0xe
.uleb128 0x8
.byte 0x85
.uleb128 0x2
.byte 0x4
.long .LCFI1-.LCFI0
.byte 0xd
.uleb128 0x5
.align 4
.LEFDE1:
.ident "GCC: (GNU) 4.1.2 20060613 (prerelease) (Ubuntu 4.1.1-2ubuntu5)"
.section .note.GNU-stack,"",@progbits
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
2006-07-01 21:09 Miles Lane
@ 2006-07-01 21:17 ` Arjan van de Ven
2006-07-01 21:25 ` Miles Lane
0 siblings, 1 reply; 31+ messages in thread
From: Arjan van de Ven @ 2006-07-01 21:17 UTC (permalink / raw)
To: Miles Lane; +Cc: Andrew Morton, LKML
On Sat, 2006-07-01 at 14:09 -0700, Miles Lane wrote:
> I am getting this:
>
> KLIBCLD usr/klibc/libc.so
> usr/klibc/execl.o: In function `execl':
> usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> usr/klibc/execle.o: In function `execle':
> usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> usr/klibc/execvpe.o: In function `execvpe':
> usr/klibc/execvpe.c:75: undefined reference to `__stack_chk_fail'
> usr/klibc/execlp.o: In function `execlp':
> usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> usr/klibc/execlpe.o: In function `execlpe':
> usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> usr/klibc/vfprintf.o:usr/klibc/vfprintf.c:26: more undefined
> references to `__stack_chk_fail' follow
> make[2]: *** [usr/klibc/libc.so] Error 1
>
> But I've searched all the .h and .c files in the tree and found no
> reference to __stack_chk_fail. I am running Ubuntu's Edgy Eft (the
> latest development tree).
somehow you're getting -fstack-protector added to your CFLAGs.. which
won't do you any good unless you link to glibc or another library that
implements the user side of the feature...
^ permalink raw reply [flat|nested] 31+ messages in thread
* 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
@ 2006-07-01 21:09 Miles Lane
2006-07-01 21:17 ` Arjan van de Ven
0 siblings, 1 reply; 31+ messages in thread
From: Miles Lane @ 2006-07-01 21:09 UTC (permalink / raw)
To: Andrew Morton, LKML
I am getting this:
KLIBCLD usr/klibc/libc.so
usr/klibc/execl.o: In function `execl':
usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
usr/klibc/execle.o: In function `execle':
usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
usr/klibc/execvpe.o: In function `execvpe':
usr/klibc/execvpe.c:75: undefined reference to `__stack_chk_fail'
usr/klibc/execlp.o: In function `execlp':
usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
usr/klibc/execlpe.o: In function `execlpe':
usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
usr/klibc/vfprintf.o:usr/klibc/vfprintf.c:26: more undefined
references to `__stack_chk_fail' follow
make[2]: *** [usr/klibc/libc.so] Error 1
But I've searched all the .h and .c files in the tree and found no
reference to __stack_chk_fail. I am running Ubuntu's Edgy Eft (the
latest development tree).
Thanks,
Miles
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2006-07-03 15:10 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <fa.iPhEst5K48JbrGWRr3l3/GEBesY@ifi.uio.no>
[not found] ` <fa.iffnN5wM1UwqtCYhmqLAkGCMC2o@ifi.uio.no>
2006-07-02 17:31 ` 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail' Robert Hancock
2006-07-02 17:44 ` H. Peter Anvin
2006-07-02 17:51 ` Arjan van de Ven
2006-07-02 18:01 ` H. Peter Anvin
[not found] <fa.WuLfTz/aICPisBh2gZXGQmS9xvs@ifi.uio.no>
[not found] ` <fa.LW8cO+QP5MhBZ9HST2AOy+N/e6o@ifi.uio.no>
2006-07-02 4:26 ` Robert Hancock
2006-07-01 21:09 Miles Lane
2006-07-01 21:17 ` Arjan van de Ven
2006-07-01 21:25 ` Miles Lane
2006-07-01 21:29 ` Arjan van de Ven
2006-07-01 22:37 ` Miles Lane
2006-07-01 22:56 ` Miles Lane
2006-07-01 23:06 ` Sam Ravnborg
2006-07-01 23:11 ` H. Peter Anvin
2006-07-01 23:26 ` H. Peter Anvin
2006-07-01 23:34 ` Miles Lane
2006-07-01 23:35 ` H. Peter Anvin
2006-07-02 3:01 ` Sam Ravnborg
2006-07-02 3:03 ` H. Peter Anvin
2006-07-02 4:05 ` Miles Lane
2006-07-02 4:52 ` H. Peter Anvin
2006-07-02 6:12 ` Miles Lane
2006-07-02 7:42 ` Arjan van de Ven
2006-07-02 17:07 ` Miles Lane
2006-07-02 17:32 ` Arjan van de Ven
2006-07-02 17:37 ` H. Peter Anvin
2006-07-02 17:50 ` Arjan van de Ven
2006-07-02 17:52 ` Arjan van de Ven
2006-07-02 18:04 ` H. Peter Anvin
2006-07-03 5:17 ` Ingo Molnar
2006-07-03 13:07 ` Miles Lane
2006-07-03 15:09 ` H. Peter Anvin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).