From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6F5AA3940CEA; Wed, 11 Mar 2020 20:14:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6F5AA3940CEA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1583957643; bh=pk+UHryFuRDXE+/3Sa4pXVQc3pZRvvd7qV/ryIfnNdM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LOEuL2IqXyyx4SCphmm4Y0qmhXldxkIl5b2joxOVd/UYlYMwRRtvuMBLTyyiXuqKO rWDaGCc+hi5GzdBSAam67YMayJTmhabDw4H2e4l6NjOEfR2+ev62NjMLqzP8+AngdI 2YuvSU1hXi1s/jv4MoI7FxaYcxeOhtL9V4G6SsVU= From: "casner at acm dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data Date: Wed, 11 Mar 2020 20:14:03 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: casner at acm dot org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 20:14:03 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94134 --- Comment #9 from Stephen Casner --- Thank you all for your prompt action on this bug. I have some comments and questions if you are willing to help with my education about gcc internals: 1. pdp11-aout does not have a .lcommon or .lcomm section, just .text, .data= and .bss. But also I'm missing something about the concept of a NOSWITCH_SECTI= ON that you can't switch to with an assembler directive -- how do you tell the assembler to assign a variable to that section if you don't emit a directiv= e? 2. Good point about optimization possibly omitting the variables in my test case. Of course, the variables were used in my real program where I first observed this problem, and I was trying to reduce my test case to the minim= um.=20 If I had tried optimization and seen them removed, I would have expanded the test case. 3. The goal that I am working toward is to have gcc and ld work correctly f= or the -msplit option in pdp11-aout. For that case, instructions and data are stored in separate, overlapping 64KB address spaces, so even if a variable = is const it can't go in the .text section. 4. I assumed that putting switch_to_section in the ASM_OUTPUT_ALIGNED_LOCAL function might not be legal since that is in the callback of a section so it might confuse the state of the caller. But if that is valid, then switchin= g to bss_section is the right thing to do because pdp11-aout does have .bss.=20 Emitting the variable in whatever section was currently active is clearly wrong. 5. Fixing the extra blank line for .globl is also good, but I was unsure why the code was as it is. Also I didn't figure out how there was a tab before .globl since it wasn't in the string constant. 6. I agree that verifying the generated assembly language is a sufficient check. But the way I run this code now is in emulation using SimH. 7. Emitting the zero-initialized variable into .data when it happens to fol= low a nonzero-initialized variable is also not correct, or at least suboptimal.= If there is a vary large uninitialized array, that would make the final execut= able output file much larger. (OK, these days a full 64KB is still a pittance, = but on principal it's suboptimal.) Therefore, switching to .bss in ASM_OUTPUT{_ALIGNED{,_DECL}_}_LOCAL is good. 8. When the variables are not static (hence global), then TREE_PUBLIC is tr= ue so it is not assigned to the lcomm_section and instead falls through to be assigned to the .data section. It seems that zero-initialized variables sh= ould be assigned to the same section whether local or global. So I think we do = need a TARGET_ASM_SELECT_SECTION function for the pdp11-aout target implemented = by a pdp11_select_section function that looks at bss_initializer_p (decl) to cho= ose between .data and .bss. Or does it need anything more of the logic like th= is from get_variable_section, or maybe define bss_noswitch_section to be bss_section if that makes sense? if (ADDR_SPACE_GENERIC_P (as) && !DECL_THREAD_LOCAL_P (decl) && !(prefer_noswitch_p && targetm.have_switchable_bss_sections) && bss_initializer_p (decl)) { if (!TREE_PUBLIC (decl) && !((flag_sanitize & SANITIZE_ADDRESS) && asan_protect_global (decl))) return lcomm_section; if (bss_noswitch_section) return bss_noswitch_section; }=