X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=from:subject:to:cc:references:message-id:date:user-agent
         :mime-version:in-reply-to:content-language:content-transfer-encoding;
        bh=JodMO8JaGdaJoVBA9POC36J8gjR1NNZrLkuOU+y7o5U=;
        b=Qae6MYxbLMZPfwU3iNGpO1gW2Ao59f+QjQvcTKWfQOAuP45HuG78fNZAPpqeO2qhfI
         aah3fw+DjZZ6PGjQeMAvBUlaVF4FszUXO09XuJoTiMol2iMTfJefnolY2Pti/xeBAW6/
         qxtSXTIehVjbCKZSrMMYtaoTkGeDqVZvGuPc7sMtQpf01TpguzcqnLFj2cGS5YEi22yU
         Os40lAtx/+uBeCbf4uTfwOprQmaWrrlzI28INOGNVuv+1jiZ0tXjomuE7OoJzCM17Ro/
         LTAz/2jrEB9PEs75p6Dfa9j3Or1u4OpmnK9Xf/0fPo3+HAaFfkJzuyrcT65MhIWVFCTe
         /gpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:from:subject:to:cc:references:message-id:date
         :user-agent:mime-version:in-reply-to:content-language
         :content-transfer-encoding;
        bh=JodMO8JaGdaJoVBA9POC36J8gjR1NNZrLkuOU+y7o5U=;
        b=N05Q6pACovKB9ROYdsvzqz6fAJJbtWawlp+0GNSaoQWuSzkwAHhSFYcfN/gOxXkmQ2
         BioDjR6GQHhq+thmGiV2DLu4apzX+nMMBPtGRt/fe2xRCABtVmJdCHhgpD7pW2+Mh9rZ
         6Kqeg73F0ys0c+oWDAmuhd5UQJGDm3FCVMSGpHuGawItXTrHw3nMuR/Z1L4qpJLrf8tb
         6nEhg7SV2FYBIP519OK9JDEsHXSd9zbVP4Y0VoYm1dk8ZHw7Kiw+NA6oFe2+LgD0c9n3
         +OzzYe1AbZ69ikkYk+ekaed2/ubnX3ME2BN3KPZEoQZWgT544bIUWXe2e2HmH+s6JZfs
         TpZA==
X-Gm-Message-State: ANhLgQ3oJP6UDfAIut3Ea+EJsaBAn133ESmWvFlfZclR1jwzSWxoszPI
	esxe7U6ZpBKl3Omf1EpyD54=
X-Google-Smtp-Source: ADFU+vuwd7kR9XN2+9PVoVJpkJbzfsw2C/HUssm9wqkPZaHkHD5lBpbPS1U2ZDOHlM041639IEmkdw==
X-Received: by 2002:adf:c449:: with SMTP id a9mr4882176wrg.366.1583938563087;
        Wed, 11 Mar 2020 07:56:03 -0700 (PDT)
From: "J.W. Jagersma (jwjagersma AT gmail DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
Subject: Re: ANNOUNCE: DJGPP port of GNU binutils 2.34 uploaded.
To: djgpp AT delorie DOT com
Cc: stsp AT users DOT sourceforge DOT net
References: <202003101900 DOT 02AJ0s2L026948 AT delorie DOT com>
Message-ID: <88b53f3e-5c10-256f-5a0c-aa942a48c6e9@gmail.com>
Date: Wed, 11 Mar 2020 15:56:00 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <202003101900.02AJ0s2L026948@delorie.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On 2020-03-10 19:58, Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via djgpp-announce AT delorie DOT com] wrote:
> This is a port of GNU binutils 2.34 to MSDOS/DJGPP.

First of all, thanks for your work to keep this port alive.  I had a
question though and would like to point out one minor issue.

>   DJGPP specific changes.
>   =======================
>   - There are no DJGPP specific changes compared with the previous port.
>     The DJGPP specific changes enumerated below are the same than the ones
>     already available in the previous port.

Are there any plans to have these changes (even partially) upstreamed
to GNU?  Because currently the upstream version is unusable even for
cross-compiling, primarily due to a missing '_environ' symbol in the
ldscripts.

>   - The linker script has been adapted to discard LTO sections created by the
>     compiler if the -flto flag is passed to the compiler.

This line has no effect though.  It reads:

    /DISCARD/ : { *(gnu.lto_*) }

but should be:

    /DISCARD/ : { *(.gnu.lto_*) }

with a leading dot in the section name.  Same issue with the dxe.ld and
djgpp.djl scripts in cvs.  Especially for DXE it can be a problem
because dxegen expects only one section in the input file.

>     This is due to LTO
>     specific file names that are not 8.3 clean especially if the -save-temps
>     option is used.  This may change in the future when the djgpp port of the
>     compiler fully supports LTO.

I thought it was only because LTO information is useless in
executables?  It's only needed during linking, and becomes just bloat
after that.