Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] eglibc: defaults to SSP
Date: Sun, 25 Aug 2013 11:11:44 +0200	[thread overview]
Message-ID: <20130825111144.052f703c@skate> (raw)
In-Reply-To: <5217BDD2.1020806@zacarias.com.ar>

Dear Gustavo Zacarias,

On Fri, 23 Aug 2013 16:53:54 -0300, Gustavo Zacarias wrote:

> This patch was never applied since it's wrong (hence i ditched it from
> patchwork).
> We need to build with -fstack-protector-all even for eglibc.
> Eglibc (at least the version we ship for internal toolchain) defaults to
> support/build stack protection support on so the option is valid.
> We don't have glibc support (yet - pending on your patches) but AFAIK
> for modern-ish versions of glibc that's also the case.
> For external toolchains, well, there's varying support i take it
> depeding on toolchain component versions.
> libssp wouldn't normally be necessary for modern toolchains except for
> MAYBE compatibility reasons which i don't think we should care about
> (old blobby apps linked against libssp) or if the toolchain has old
> components so libssp shouldn't necessarily be copied, at least not as a
> default.
> Doing the nasty trick with sourcery 2013.05 ARM (qemu_arm_versatile)
> with BR2_TARGET_OPTIMIZATION="-fstack-protector-all" works fine for
> example without the need for tweaks.

Ok, so if we try to summarize this:

 * The option to enable SSP should be in "Build options" and not in the
   "Toolchain" menu, because what it mainly does is adjust the
   CFLAGS/CXXFLAGS for all packages.

 * In the case of the internal toolchain backend, it would make sure
   that the SSP support in the C library in enabled. I.e, nothing for
   eglibc/glibc, and enable SSP for uClibc.

 * In the case of the external toolchain backend, we would need to have
   an option like "Toolchain supports SSP?" that the user must fill in.
   But this would mean the "Use SSP" option in "Build options" would
   have to depend on the "Toolchain supports SSP?" option.

Something like that?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2013-08-25  9:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-27 14:32 [Buildroot] [PATCH] eglibc: defaults to SSP Gustavo Zacarias
2013-08-23 19:09 ` Thomas Petazzoni
2013-08-23 19:53   ` Gustavo Zacarias
2013-08-25  9:11     ` Thomas Petazzoni [this message]
2013-08-25 11:59       ` Gustavo Zacarias
2013-08-26 22:03         ` Thomas Petazzoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130825111144.052f703c@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox