public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@adacore.com>
To: JonY <10walls@gmail.com>
Cc: NightStrike <nightstrike@gmail.com>,
	       "Joseph S. Myers" <joseph@codesourcery.com>,
	       GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: introduce --enable-mingw-full32 to default to --large-address-aware
Date: Thu, 08 Nov 2018 09:45:00 -0000	[thread overview]
Message-ID: <or4lcr3nt0.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <5704d23a-37d1-4cc7-c131-7dac969d1635@gmail.com> (JonY's message	of "Wed, 7 Nov 2018 12:49:50 +0000")

On Nov  7, 2018, JonY <10walls@gmail.com> wrote:

> On 11/07/2018 08:34 AM, Alexandre Oliva wrote:
>> On Nov  1, 2018, JonY wrote:
>> 
>>> Looks like it causes an error on 64bit:
>>> /usr/libexec/gcc/x86_64-w64-mingw32/ld: unrecognized option
>>> '--large-address-aware'
>> 
>> What does?  The patch I suggested?  The current trunk?
>> 
>> What was the command in this case?  How was the toolchain configured?

> No it's just a quick test to see how x86_64-w64-mingw32 reacts to
> --large-address-aware, it doesn't play well.

I understand, but you're getting a different result from what I am, I'd
like to understand why before attempting to "fix" something that AFAICT
is correct and behaving just as intended.  Maybe there are valid reasons
to drop --large-address-aware altogether on x86_64-w64-mingw32, but I'd
like to understand why, as in, how the error above came about for you,
when it didn't for me.

I built gcc and binutils in a single tree, with x86_64-w64-mingw32 as
the target, and the resulting linker would accept --large-address-aware
in the -mi386-pe emulation, and that emulation was explicitly enabled
when building -m32 binaries.  Does your w64 toolchain deviate from any
of these facts?


> x86_64-mingw32 is not used as far as I know, only with "w64" or "pc".

x86_64-mingw32's canonical form is x86_64-pc-mingw32, and they're
equivalent, so whatever you say or know about the latter should apply to
the shorter form as well.  Likewise, my questions and doubts about the
shorter form apply equally to the canonical one.

> The "w64" carries a special meaning to gcc dating back to the early
> 64bit port. It basically tells gcc to use mingw-w64 specific features
> that are not found on the regular mingw.org CRT at the time.

I see.  So -pc- and -w64- are not supposed to be equivalent indeed.
Thanks.

> This might be affecting the "pc" vendor build, can you check
> x86_64-pc-mingw32 just to see if it is affected?

I did.  Its -m32 mode seems broken to me.  As I wrote, the linker
emulation is never specified, so it would build 64-bit binaries even
when given -m32.  Because it lacks explicit linker emulation
specification, it can't have --large-address-aware specified either.

In my link tests, i686-mingw32 and x86_64-w64-mingw32 both worked (in
that their respective linkers wouldn't reject the --large-address-aware
passed by gcc) with the --large-address-aware patch that is installed in
trunk.  Ditto with the incremental patch I posted last week, that would
have only improved x86_64-pc-mingw32.

-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free!         FSF Latin America board member
GNU Toolchain Engineer                Free Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe

  reply	other threads:[~2018-11-08  9:45 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-05  6:48 Alexandre Oliva
2018-10-05 16:40 ` Joseph Myers
2018-10-09  6:38   ` Alexandre Oliva
2018-10-09 11:31     ` JonY
2018-10-10  4:58       ` Alexandre Oliva
2018-10-10  5:20         ` JonY
2018-10-10  8:00           ` Alexandre Oliva
2018-10-11  0:18             ` JonY
2018-10-11  7:46               ` NightStrike
2018-10-11 11:32                 ` JonY
2018-10-12  6:28                   ` Alexandre Oliva
2018-10-12 11:27                     ` JonY
     [not found]                     ` <ork1lxspuw.fsf@lxoliva.fsfla.org>
2018-11-01 10:48                       ` JonY
2018-11-07 11:59                         ` Alexandre Oliva
2018-11-07 12:50                           ` JonY
2018-11-08  9:45                             ` Alexandre Oliva [this message]
2018-11-08 15:39                               ` JonY
2018-11-09 10:49                                 ` Alexandre Oliva
2018-11-09 12:22                                   ` JonY
2018-10-07  8:03 ` JonY

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=or4lcr3nt0.fsf@lxoliva.fsfla.org \
    --to=oliva@adacore.com \
    --cc=10walls@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=nightstrike@gmail.com \
    /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).