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=subject:from:to:references:message-id:date:user-agent:mime-version
         :in-reply-to:content-language:content-transfer-encoding;
        bh=INUy3yvgE2enmJerFfgEilZYDOdbYwCJB/DerP7Mzc0=;
        b=bNiCjr8XU2/LKTtjMTvoE27reL7tacBXEJLTAX5adcfvQ69RWW141MCeEoIJiOshiZ
         4uG1TIyEUJDoWJGXqmMniw++5KwJKaMudhoLTu83NjMiIidAFuUXKh55W1alXWNmFb8z
         7D76wG41DZoAXwjM1AIll0Uwo/OPJokTZMwmOaHl6pqxeGHYW49C+YBc07ViUhrDV9iO
         +psXLO80HFTqEQb6FcvgCB2HBNn77BiHpn5NS/Xhx0CwfdAO7i+YoGNSOvQX9Ua/3PNe
         V67ZyeWrR4aLIMZfZvmWgJHq5O57iWBftHbcL/7TRjTIJwVRPL3felvTR8T634K9+ns5
         GEog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:subject:from:to:references:message-id:date
         :user-agent:mime-version:in-reply-to:content-language
         :content-transfer-encoding;
        bh=INUy3yvgE2enmJerFfgEilZYDOdbYwCJB/DerP7Mzc0=;
        b=l/1kSgAqsiMBVd4vSIPvCn+EsesaWZqj5hoNrTnF1rWc8L0yalQoO+Mn5BkmPR/m59
         fsAqx4LLpvSx3awATCBkXds2vz8G6qtcdbYDtTjs2Z8IFWulW5x9+BZMsYhbCgOo6xsH
         W4hFc79KJ8rCBxVlV7sZR2oeNJaJTU/bdYuwFAIy5dA3EGtrfZEdgB4AF23cHthF6iME
         RVfX3sNrL70JpIU7I3YYwjkMglgvXKVEi/0s/H8hPw7uAj/jH7Pk4ILCTyGZCrJxrp8Q
         QqIDSR58Ro0FJIC869cfc4crig9THpHdcQV1bYKz2oBdkWAwlnu3CdFhWElFKSHeO7E2
         k3eQ==
X-Gm-Message-State: ANhLgQ1SWkfforucyxllL8fg0lDCi9O0JPaHRqCV3cswvG2hxnnToOX3
	BzeJeH2fVOK/UGIp6CSlb6TJ44n+sZE=
X-Google-Smtp-Source: ADFU+vsZPST+1iYT3pS5UeGUChOxXFPsjjuCjlFbKgeFEUZmFRv8pSjKICATiYnqM4rWHKAfPQpK8g==
X-Received: by 2002:a5d:4ac8:: with SMTP id y8mr25118571wrs.272.1584909026833;
        Sun, 22 Mar 2020 13:30:26 -0700 (PDT)
Subject: Re: ANNOUNCE: DJGPP port of GNU binutils 2.34 uploaded.
From: "J.W. Jagersma (jwjagersma AT gmail DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
To: djgpp AT delorie DOT com
References: <202003101900 DOT 02AJ0s2L026948 AT delorie DOT com>
 <5d1762a4-d2ba-41cc-b5ab-432afe533657 AT gmail DOT com>
Message-ID: <23a5d069-288e-ca3a-6e10-2746d1274868@gmail.com>
Date: Sun, 22 Mar 2020 21:30:23 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <5d1762a4-d2ba-41cc-b5ab-432afe533657@gmail.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-21 20:45, J.W. Jagersma wrote:
> 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.
> 
> I have another question, about this part in the ldscript:
> 
>     /* Ugly workaround to prevent entire .bss to have attribute CONTENT */
>     /* for C++ executables. */
>     *(.bss.*)
> 
> What does this mean exactly, why is it bad for .bss to have this
> attribute?  Would it be a good idea to send this upstream or should a
> better solution be found first?
> 
> Or can it be removed entirely?  When I compile some C++ code I only see
> a single .bss section, no .bss.* subsections.  So I'm not even sure if
> this does anything at all.

Okay, I found that CONTENTS determines if the section should have space
allocated for it in the output file.  I can see how that's a problem
for a .bss section (my previous question may have come across as a bit
stupid :) ).

In libstdc++.a I see there are some .bss.* sections.  However the
workaround still doesn't have the effect it claims to have, because in
my executables I still see CONTENTS set for .bss.  The problem is that
.gnu.linkonce.b.* sections also have CONTENTS set, so to work around
that, they would also have to be linked in .data.  But that doesn't
achieve much - from some quick experimentation I find that the linkonce
sections take up the most space, so the size difference is minimal.

Or, of course, this flag shouldn't be set for these sections in the
first place.  I think the assembler does this?  Why is this not a
problem for other targets, how do they deal with this?