[Bug target/94085] New: pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94085
Bug ID: 94085
Summary: pdp11-aout puts initial variable into .text section
rather than .data
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: casner at acm dot org
Target Milestone: ---
The assembler output for a C program compiled for the pdp11-aout target begins
with a .text directive. If that program begins with a variable that is not
initialized to a nonzero value, that variable will be left if the .text section
rather than being allocated to the .data section. If the first variable is
initialized to a nonzero value, then a .data directive is inserted after the
.text directive to switch sections. This bug matters for formats where the
text section is read-only or with split instruction and data spaces.
I selected component target, but I don't know if this problem is specific to
the pdp11-aout target.
Here is a simple example showing this problem:
Command: pdp11-aout-gcc -ffreestanding -nostdlib -S -o zero.s zero.c
static int zero = 0;
static int one = 1;
int main() {}
.text
.even
_zero: .=.+ 02
.data
.even
_one:
.word 01
.text
.even
.globl _main
_main:
setd
seti
mov r5,-(sp)
mov sp,r5
jsr pc,___main
nop
mov (sp)+,r5
rts pc
If the first variable is initialized to a nonzero value, the output is correct:
Command: pdp11-aout-gcc -ffreestanding -nostdlib -S -o one.s one.c
static int one = 1;
static int zero = 0;
int main() {}
.text
.data
.even
_one:
.word 01
.even
_zero: .=.+ 02
.text
.even
.globl _main
_main:
setd
seti
mov r5,-(sp)
mov sp,r5
jsr pc,___main
nop
mov (sp)+,r5
rts pc
My environment is a macOS host and pdp11-aout target.
GNU C17 (GCC) version 10.0.1 20200303 (experimental) (pdp11-aout)
compiled by GNU C version 4.2.1 Compatible Apple LLVM 11.0.0
(clang-1100.0.33.17), GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0,
isl version isl-0.20-GMP
Configured with: ../configure --target=pdp11-aout --prefix=/usr/local
--disable-libstdc++-v3 --disable-libssp --disable-libgfortran --disable-libobjc
--disable-libbacktrace --with-gmp=/opt/local/ --with-mpfr=/opt/local/
--with-mpc=/opt/local/
[Bug target/94134] New: pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134
Bug ID: 94134
Summary: pdp11-aout puts initial variable into .text section
rather than .data
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: casner at acm dot org
Target Milestone: ---
The assembler output for a C program compiled for the pdp11-aout target begins
with a .text directive. If that program begins with a variable that is not
initialized to a nonzero value, that variable will be left if the .text section
rather than being allocated to the .data section. If the first variable is
initialized to a nonzero value, then a .data directive is inserted after the
.text directive to switch sections. This bug matters for formats where the
text section is read-only or with split instruction and data spaces.
I selected component target, but I don't know if this problem is specific to
the pdp11-aout target.
Here is a simple example showing this problem:
Command: pdp11-aout-gcc -ffreestanding -nostdlib -S -o zero.s zero.c
static int zero = 0;
static int one = 1;
int main() {}
.text
.even
_zero: .=.+ 02
.data
.even
_one:
.word 01
.text
.even
.globl _main
_main:
setd
seti
mov r5,-(sp)
mov sp,r5
jsr pc,___main
nop
mov (sp)+,r5
rts pc
If the first variable is initialized to a nonzero value, the output is correct:
Command: pdp11-aout-gcc -ffreestanding -nostdlib -S -o one.s one.c
static int one = 1;
static int zero = 0;
int main() {}
.text
.data
.even
_one:
.word 01
.even
_zero: .=.+ 02
.text
.even
.globl _main
_main:
setd
seti
mov r5,-(sp)
mov sp,r5
jsr pc,___main
nop
mov (sp)+,r5
rts pc
My environment is a macOS host and pdp11-aout target.
GNU C17 (GCC) version 10.0.1 20200303 (experimental) (pdp11-aout)
compiled by GNU C version 4.2.1 Compatible Apple LLVM 11.0.0
(clang-1100.0.33.17), GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0,
isl version isl-0.20-GMP
Configured with: ../configure --target=pdp11-aout --prefix=/usr/local
--disable-libstdc++-v3 --disable-libssp --disable-libgfortran --disable-libobjc
--disable-libbacktrace --with-gmp=/opt/local/ --with-mpfr=/opt/local/
--with-mpc=/opt/local/
[Bug target/94085] pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94085 Stephen Casner changed: What|Removed |Added CC||casner at acm dot org This bug lost its comments in the sourceware/gcc move and also lost the fact that I had submitted it because my account was also lost. Rather than trying to repair this bug, I have entered a new one, bug 94134.
[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134 Stephen Casner changed: What|Removed |Added Target||pdp11-aout --- Comment #1 from Stephen Casner --- I would be happy to work on implementing a fix for this bug if someone can point me in the right direction. I tried defining a TARGET_ASM_SELECT_SECTION function for the pdp11-aout target that always returns data_section, but the result was unchanged. I verified that function was only called once when compiling my test program, that was at the point the .data directive was emitted. Then I stepped through the code in varasm.c to understand a bit about why this happens. Because the test program variable is not initialized to a nonzero value, bss_initializer_p returns true, and consequently get_variable_section returns lcomm_section. Because lcomm_section is of style SECTION_NOSWITCH, assemble_variable calls assemble_noswitch_variable to generate the output rather than calling switch_to_section and assemble_variable_contents as is what happens to generate the .data directive before my test program variable that _is_ initialized to a nonzero value. assemble_noswitch_variable generates the assembler output by calling the callback of the section, which for lcomm_section is emit_local. emit_local calls ASM_OUTPUT_ALIGNED_LOCAL which has been defined for the pdp11-aout target and implemented in pdp11_asm_output_var. A partial fix might be to have that function output a .bss directive ahead of the zero-initialized variable. A side comment is that I have not seen any .bss directive even in the output from the real C program that led me to observe this bug. But since we can't switch in_section to lcomm_section, I don't know to avoid emitting .bss ahead of every zero-initialized (or uninitialized) variable even when there are several in a row. Furthermore, the comment for #define SECTION_NOSWITCH says that it is for sections that we cannot switch to with an assembler directive (like .bss), so perhaps the logic leading to the choice of lcomm_section is not appropriate for the pdp11_aout target. In addition, if the "static" is removed from the zero-initialized variable declaration in my test program so it is global, then TREE_PUBLIC is true 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 should be assigned to the same section whether local or global.
[Bug target/94085] pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94085 --- Comment #1 from Stephen Casner --- Please mark this bug RESOLVED DUPLICATE of bug 94134.
[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134
--- 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_SECTION
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 directive?
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 minimum.
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 for
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 switching to
bss_section is the right thing to do because pdp11-aout does have .bss.
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 follow
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 executable
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 true
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 should
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 choose
between .data and .bss. Or does it need anything more of the logic like this
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;
}
[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134 --- Comment #10 from Stephen Casner --- One more question: I'm working on binutils ld as well, wanting to implement a new option --imagic for pdp11-aout that outputs magic number 0413 and sets both .text and .data at address 0 (with .bss to follow .data). If -msplit is included as a compilation option, then --imagic should be passed to the linker. I'd appreciate a pointer to where that should happen.
[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134
--- Comment #12 from Stephen Casner ---
(In reply to pkoning from comment #11)
> (In reply to Stephen Casner from comment #9)
> > 7. Emitting the zero-initialized variable into .data when it happens to
> > follow 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 executable 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.
>
> Yes, if the assembler/linker supports that, but my understanding is that
> they do not. It would be lovely if we could have ELF for pdp11...
Although .bss is not defined as a general GNU Assembler directive, it is
defined as a PDP-11 dependent feature. It was also included in the PDP11 Unix
assembly language as produced by cc on 2.11BSD, for example:
user[47] cat > array.c
static int zero[1000];
static int one[1000] = { 1 };
int main() {}
user[48] cc -S -o array.s array.c
user[49] cat array.s
.globl
.bss
_zero:
.=.+3720
.data
_one:
1
.=.+3716
.globl _main
.text
_main:
~~main:
jsr r5,csv
jbr L1
L2:L3:jmp cret
L1:jbr L2
.globl
.data
user[50]
This array.s is not accepted by GNU as because of the .globl without a symbol,
the constant 1 without .word, and the jbr mnemonic.
[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134
--- Comment #13 from Stephen Casner ---
(In reply to Stephen Casner from comment #9)
(Commenting on my own comment)
> 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_SECTION 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 directive?
The a.out file format produced by the assembler or linker includes only the
.text, .data and .bss sections. However, that does not mean the compiler could
not pass a .comm or .lcomm directive to the assembler. I now understand those
and the NOSWITCH concept. In fact, I found that the Unix v6 cc produces the
.comm directive which I had not seen before:
# cat > static.c
int zero;
int one;
int main() {
static int two;
zero = 0;
one = 1;
two = 2;
}
# cc -S static.s static.c
# cat static.s
.globl _zero
.comm _zero,2
.globl _one
.comm _one,2
.globl _main
.text
_main:
~~main:
.bss
L2:.=.+2
.text
~two=L2
jsr r5,csv
clr _zero
mov $1,_one
mov $2,L2
L1:jmp cret
.globl
.data
#
So presumably the ASM_OUTPUT{_ALIGNED{,_DECL}_}_LOCAL functions could generate
.comm and .lcomm directives to be allocated to the .bss section by as. I don't
know if there is enough size information in the relocation section of the a.out
file to allow merging global .comm declarations.
[Bug c++/94835] New: ICE in vague_linkage_p, at cp/decl2.c:2041
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94835 Bug ID: 94835 Summary: ICE in vague_linkage_p, at cp/decl2.c:2041 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: casner at acm dot org Target Milestone: --- I am working on a pdp11-elf32 target in binutils with the goal of being able to compile C++ for the PDP11 (an effort instigated by Paul Koning, gcc PDP11 maintainer). I have a first implementation running, so now I am trying to build g++ and libstdc++v3 to go with it. I am attempting to build the gcc tree with newlib and libgloss symlinked in and with the binutils components installed at the prefix and with gcc configured as follows: ../configure --target=pdp11-elf32 --prefix=/usr/local --enable-languages=c,c++ --disable-libssp --disable-libgfortran --disable-libobjc --with-gmp=/opt/local/ --with-mpfr=/opt/local/ --with-mpc=/opt/local/ --with-libiconv-prefix=/opt/local --with-newlib My host is running macOS 10.14.6. gcc and g++ build successfully, but while building libstdc++v3 I get: .../libstdc++-v3/include/chrono:544:7: internal compiler error: in vague_linkage_p, at cp/decl2.c:2041 This is with code freshly fetched with git today. 19667c82e479dc2bf8351588ed57aff90220b748
[Bug c++/94835] ICE in vague_linkage_p, at cp/decl2.c:2041
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94835 --- Comment #1 from Stephen Casner --- Created attachment 48398 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48398&action=edit preprocessed source chrono.ii
[Bug c++/94835] ICE in vague_linkage_p, at cp/decl2.c:2041
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94835 --- Comment #2 from Stephen Casner --- Created attachment 48400 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48400&action=edit log of compilation with -v (Not sure why the initial attachment was deleted.)
[Bug c++/94835] ICE in vague_linkage_p, at cp/decl2.c:2041
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94835 --- Comment #3 from Stephen Casner --- I'm working with unmodified gcc sources, but if no other targets are seeing this problem then it may be caused by pdp11-specific code somewhere else. I guess that g++ and libstdc++v3 have never been successfully built for pdp11. Any suggestions for debugging this? Perhaps backing off on some compiler feature that might be tickling the bug?
[Bug c++/94835] ICE in vague_linkage_p, at cp/decl2.c:2041
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94835 --- Comment #4 from Stephen Casner --- I verified that the compilation of chrono:544 is the first time in the build that the failing assert is executed, so that likely implies that the problem is general and not specific to the particular source code. The only mentions of COMDAT in the pdp11 backend are the macros #define TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT hook_bool_void_false #define TARGET_CXX_LIBRARY_RTTI_COMDAT hook_bool_void_false These are in the direction that make the assert true rather than false, so changing those to the default hook_bool_void_true wouldn't help (and would presumably cause something else to fail). I'm way out of my league here, so any suggestions would be appreciated.
[Bug c++/94835] ICE in vague_linkage_p, at cp/decl2.c:2041
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94835 Stephen Casner changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #5 from Stephen Casner --- This ICE occurred because my additions to config.gcc were incomplete. Those additions did not include elfos.h for pdp11-elf32 so SUPPORTS_ONE_ONLY==0 and TARGET_SUPPORTS_WEAK==0 which caused have_weak==false which caused comdat_linkage() to set TREE_PUBLIC(decl)=0, resulting in the assert failure. This was probably not a supported configuration for compiling C++ code.
[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134 --- Comment #17 from Stephen Casner --- Thanks.
