https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134
--- Comment #11 from pkoning at gcc dot gnu.org ---
(In reply to Stephen Casner from comment #9)
A lot of these questions should have answers in the GCC Internals manual, which
is quite good. And also quite dense. I know it a little, enough for a bunch
of cleanup on the pdp11 target in recent years, but I'm certainly not an
expert. The gcc mailing list is where you find experts. Some comments below
for the parts I can answer:
> ...
> 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.
The test case was fine. What I meant is that when I compiled with -O1, the
back end would emit b followed by a, which wouldn't show the problem because
emitting b would correctly send the .data even in the old code.
>
> 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.
Yes. Ideally as/ld would support .rodata, but without that it has to be .data.
>...
> 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.
The assembler doesn't actually care about any of that, so it's just a matter of
aiming for reasonable consistency to make the assembly code somewhat readable.
The code generator isn't all that consistent, but there isn't any reason for
that as far as I am aware.
>...
> 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...
---
On the linker option tied to -msplit, I haven't used this but the GCC Internals
manual gives the answer, in "18.2 Controlling the Compilation Driver, ‘gcc’" --
LINK_SPEC will do this.
