that gas "MIPS ELF reloc" testsuite failure.

[cgd at sibyte dot com (Chris G. Demetriou)]

So, several folks have noted that the gas "MIPS ELF reloc" test
started failing sometime in the last several months, with log info
like:

../as-new   -o dump.o /home/cgd/old-binutils/binutils-current/src/gas/testsuite/gas/mips/elf-rel.s
/home/cgd/old-binutils/binutils-current/mips-elf/gas/testsuite/../../binutils/objdump  -sr -j .text dump.o > dump.out
extra lines in dump.out starting with "^ 0060 00000000 00000000 00000000 00000000  ................$"
EOF from /home/cgd/old-binutils/binutils-current/src/gas/testsuite/gas/mips/elf-rel.d 
FAIL: MIPS ELF reloc

I tracked this down, and it goes back to RTH's changes on 2000-12-28,
which added a chunk of code to subsegs_finish() that looks like:

      /* The last subsegment gets an aligment corresponding to the
         alignment of the section.  This allows proper nop-filling
         at the end of code-bearing sections.  */
      if (!frchainP->frch_next || frchainP->frch_next->frch_seg != now_seg)
        alignment = get_recorded_alignment (now_seg);


The MIPS ELF reloc test sets alignment of 2^15, but the assumed that
the zero padding at the end of the section due to alignment wouldn't
actually be generated by the assembler or placed into the object file.

A quick check of a data section, using the source file:

        .data
        .p2align 15
        .word 0

indicates that data, too, will now be padded out in the object file
(_always_ with zeroes).  (Previously, only the .word's data would show
up in the object file.)


I don't really know what the 'right' behaviour here is.

If you've set alignment for a section and the remainder will be zero
filled, _should_ the assembler actually emit those zeroes?

For a text section, i think this is somewhat arguable.  (After all,
even if nop is 0, what you've got are logically nops, not zeroes.)
However, emitting those zeroes _is_ a change in behaviour.

For a data section, it seems to me that there's really no reason to
add the extra padding.


The data case is easy to fix.  E.g. the test mentioned above can be
changed so that it looks like:

      if (subseg_text_p(now_seg)
          && (!frchainP->frch_next
              || frchainP->frch_next->frch_seg != now_seg))
        alignment = get_recorded_alignment (now_seg); 

(and the comment should be adjusted, of course 8-).

If "The Right Thing" for text is not emitting the extra zeroes, that
looks harder.  I think that in the worst case you'd need a runtime
test to tell you whether the alignment padding _would be_ zero filled
or not.  (e.g. for MIPS, it's not zero filled if compiling mips16
instructions, but if compiling normal MIPS instructions it is.)

If "The Right Thing" for test _is_ emitting the extra zeroes, then the
MIPS ELF reloc test needs to be updated.  Easy enough.  8-)


Thoughts?


chris