Re: mn10300: relaxing vs section merging

[Alexandre Oliva <aoliva@redhat.com>]

On May  6, 2004, DJ Delorie <dj@redhat.com> wrote:

>> I don't recall the exact details, but what I recall had to do with
>> losing information that was essential for (some definition of) correct
>> relaxation.
>> I do remember having run into this one problem years ago.  I probably
>> thought the same anchoring issue could very well show up in other
>> relocation types, and just disabled adjusting for them all.  Perhaps
>> it's safe to enable adjusting, at least as long as the addend is zero.

>> > You have to use section-relative relocs with section merging

>> Why?

> Because _bfd_elf_rela_local_sym() only adjusts STT_SECTION symbols.
> If you have other types of symbols, it doesn't seem to adjust the
> values properly.

Hmm...  Maybe it should be improved/fixed, then?  I suppose whenever
we get called with a symbol, we should figure out in which section it
is, find the relocation for the section, and then apply the symbol
offset into the section again.

>> Anyhow...  I don't see how this could actually work in the general
>> case, since mn10300_fix_adjustable() actually refuses to adjust
>> relocations that reference symbols in code sections.

> The case that's failing is thusly, where the symbol referenced is in
> the merged rodata section and gets moved too far away through merging:

> 	.text
> 	mov	.L1,d1

> 	.section	.rodata.str1.1,"aMS",@progbits,1
> .L1:
> 	.string	"\n"

This case could definitely be turned into a section symbol, even
though it's relaxable.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}