This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: that gas "MIPS ELF reloc" testsuite failure.


cgd@sibyte.com (Chris G. Demetriou) writes:

> 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.

I don't think the behaviour you are describing is right when using
ELF.  In ELF, we can represent the size of a section without actually
filling in the data.  We shouldn't actually write the data.  I can see
why the change is desirable for sections which don't zero fill, but
for sections which do zero fill I don't think we should do this.  At
least if we can figure that out.

> 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-).

Looks good to me.

> 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-)

The .text case is less interesting than the .data case.  I think it's
probably OK to zero-fill .text, although it is not ideal.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]