From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 4A2733858D37 for ; Fri, 23 Jun 2023 06:37:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4A2733858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0353729.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 35N65uhk003146 for ; Fri, 23 Jun 2023 06:37:39 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : from : subject : to : content-type : content-transfer-encoding; s=pp1; bh=qx+hZcTeI82uUQ35DgcIH40dkskwEi847TfON4BHBw0=; b=axrY7Ei0zsGCBOiQI2w58xIo6OQVt+DXv+9D6bSBhs3HfxrN7PJRV6NPpL0edZpCK8ka VGg0rNQpjml28gHEL/TuFRGYpgePxzCa3sdoIz5ix8hWCshrn0GHWAedleDGdrrc0BK9 bZ5TKaQkpb4YuL8zYThkYOxGocfIWYfwgo587cLTJ8mbgOepTMcjrovQu1Df1/arxJ37 HEbSmqWRa/EWTJv3Tw/SNfc8gyP91q17pImmln1kgG6zOv6+aR+nR4FjJnlB4Qmm83Bw 0jE0bBE/WBIJ3dFLGKY0npASc3FZbqLv+TwS3ybGREAxTXXbQ++zskZBs56EfooZWOuJ PQ== Received: from ppma04ams.nl.ibm.com (63.31.33a9.ip4.static.sl-reverse.com [169.51.49.99]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rd4rshyha-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 23 Jun 2023 06:37:38 +0000 Received: from pps.filterd (ppma04ams.nl.ibm.com [127.0.0.1]) by ppma04ams.nl.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 35N2bH7D013895 for ; Fri, 23 Jun 2023 06:37:36 GMT Received: from smtprelay07.fra02v.mail.ibm.com ([9.218.2.229]) by ppma04ams.nl.ibm.com (PPS) with ESMTPS id 3r94f5c0cm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 23 Jun 2023 06:37:36 +0000 Received: from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com [10.20.54.104]) by smtprelay07.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 35N6bXHW59376078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 23 Jun 2023 06:37:33 GMT Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B9F6F20043 for ; Fri, 23 Jun 2023 06:37:33 +0000 (GMT) Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 960F520040 for ; Fri, 23 Jun 2023 06:37:33 +0000 (GMT) Received: from [9.179.28.243] (unknown [9.179.28.243]) by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTP for ; Fri, 23 Jun 2023 06:37:33 +0000 (GMT) Message-ID: Date: Fri, 23 Jun 2023 08:37:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US From: Andreas Krebbel Subject: [RFC] Make __bss_start point at actual start of .bss To: "binutils@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: hBHFMVkQyAtjPZ2fZM1wzcRG66zIwWdN X-Proofpoint-GUID: hBHFMVkQyAtjPZ2fZM1wzcRG66zIwWdN X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-06-23_02,2023-06-22_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 impostorscore=0 lowpriorityscore=0 bulkscore=0 phishscore=0 spamscore=0 priorityscore=1501 mlxlogscore=834 suspectscore=0 clxscore=1015 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2306230059 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, the way __bss_start is defined in our default linker script right now makes it point after the .data section instead of the actual start of .bss. The symbol is defined outside of the section definition and therefore is not moved together with the .bss section if ld applies any alignment to it. This not only is very counterintuitive but also triggers a problem on zSystems. All our symbols need to be 2 byte aligned. If .data has an odd size this symbol is misaligned and thereby not ABI conform anymore. While we could add platform-dependent alignment for the symbol here I'm wondering whether we perhaps should rather move __bss_start into the .bss section definition in order to have it point at the actual start of the section. I've checked that even if there is no input .bss ld will create an empty .bss output section if the symbol is referenced. I've also checked with mold and lld. Both linkers put __bss_start at the actual beginning of .bss as one would expect. Does anything speak against doing the same with ld? Andreas