public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Christian Biesinger via gdb-patches <gdb-patches@sourceware.org>
Cc: Christian Biesinger <cbiesinger@google.com>
Subject: Re: [PATCH v2] Don't define _FORTIFY_SOURCE on mingw
Date: Thu, 02 Jan 2020 11:31:00 -0000	[thread overview]
Message-ID: <20200102113102.GA4137@adacore.com> (raw)
In-Reply-To: <20191218190705.161582-1-cbiesinger@google.com>

Hi everyone,

On Wed, Dec 18, 2019 at 01:07:05PM -0600, Christian Biesinger via gdb-patches wrote:
> Recent mingw versions require -lssp when using _FORTIFY_SOURCE, which
> gdb does (in common-defs.h)
> https://github.com/msys2/MINGW-packages/issues/5868#issuecomment-544107564
> 
> To avoid all the complications with checking for -lssp and making sure it's
> linked statically, just don't define it.
> 
> gdb/ChangeLog:
> 
> 2019-12-18  Christian Biesinger  <cbiesinger@google.com>
> 
> 	* gdbsupport/common-defs.h: Don't define _FORTIFY_SOURCE on mingw.

Thanks for the patch!

I hestitated a lot on this patch. On the one hand, it wasn't clear
to me that libssp was any different from the other library dependencies
that one can build against... Until it was mentioned that static linking
requires libssp_nonshared! Gaaah... Also, while some people consider it
a necessity to link statically, others would can be in a situation where
it is definitely better for them to link dynamically.

At the end of the day, I think this might be the most sensible approach
after all. I imagine that someone wanting to build with FORTIFY can do
so by adding -D_FORTIFY_SOURCE=2 to the compilation flags, and then
the necessary linking options to add the libraries. For static linking,
one can pass the full path to the archive instead of using -lxxx.
In other words, this patch isn't closing the door for activating
_FORTIFY_SOURCE.

I was also thinking of adding a NEWS entry. However, IIUC, this option
had no effect with previous versions of MinGW? Thus, in the end,
this patch makes the situation stay the same regardless of MinGW
version, meaning no NEWS updated needed.

If my understanding is correct, then I am OK with this patch, and
you can push it to both master and gdb-9-branch. Even if people
object to the approach, this patch doesn't make it any more difficult
to enhance the build to have fortify on by default.

One small comment below...

> 
> Change-Id: Ide6870ab57198219a2ef78bc675768a789ca2b1d
> ---
>  gdb/gdbsupport/common-defs.h | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/gdb/gdbsupport/common-defs.h b/gdb/gdbsupport/common-defs.h
> index 203bd8972d..53ce3c96ea 100644
> --- a/gdb/gdbsupport/common-defs.h
> +++ b/gdb/gdbsupport/common-defs.h
> @@ -66,9 +66,13 @@
>     plus this seems like a reasonable safety measure.  The check for
>     optimization is required because _FORTIFY_SOURCE only works when
>     optimization is enabled.  If _FORTIFY_SOURCE is already defined,
> -   then we don't do anything.  */
> +   then we don't do anything.  Also, on mingw, fortify requires

mingw -> MinGW ;-)

> +   linking to -lssp, and to avoid the hassle of checking for
> +   that and linking to it statically, we just don't define
> +   _FORTIFY_SOURCE there.  */
>  
> -#if !defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__ > 0
> +#if (!defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__ > 0 \
> +     && !defined(__MINGW32__))
>  #define _FORTIFY_SOURCE 2
>  #endif
>  
> -- 
> 2.24.1.735.g03f4e72817-goog

-- 
Joel

  reply	other threads:[~2020-01-02 11:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-18 18:14 [PATCH] Link to -lssp when available (fixes mingw build) Christian Biesinger via gdb-patches
2019-12-18 18:23 ` Christian Biesinger via gdb-patches
2019-12-18 18:45 ` Eli Zaretskii
2019-12-18 18:57   ` Christian Biesinger via gdb-patches
2019-12-18 19:07     ` [PATCH v2] Don't define _FORTIFY_SOURCE on mingw Christian Biesinger via gdb-patches
2020-01-02 11:31       ` Joel Brobecker [this message]
2020-01-07 23:43         ` Christian Biesinger via gdb-patches
2020-01-08  3:30           ` Eli Zaretskii
2020-01-09 22:23           ` Tom Tromey
2020-01-09 22:32             ` Christian Biesinger via gdb-patches
2020-01-10  0:28               ` Tom Tromey
2020-01-10 17:41                 ` Christian Biesinger via gdb-patches
2019-12-18 19:08     ` [PATCH] Link to -lssp when available (fixes mingw build) Eli Zaretskii
2019-12-18 19:12       ` Christian Biesinger via gdb-patches
2019-12-18 19:40         ` Eli Zaretskii
2019-12-18 19:50           ` Christian Biesinger via gdb-patches
2019-12-18 19:57             ` Eli Zaretskii
2019-12-18 20:41               ` Christian Biesinger via gdb-patches
2019-12-18 23:12                 ` Eli Zaretskii
2019-12-18 23:24                   ` Christian Biesinger via gdb-patches
2019-12-19 14:19                     ` Pedro Alves
2019-12-19 15:49                       ` Eli Zaretskii
2020-02-15 14:06                         ` Eli Zaretskii
2019-12-19 20:41                       ` Christian Biesinger via gdb-patches
2019-12-19 15:32                     ` Eli Zaretskii

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=20200102113102.GA4137@adacore.com \
    --to=brobecker@adacore.com \
    --cc=cbiesinger@google.com \
    --cc=gdb-patches@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).