Re: mn10300: relaxing vs section merging

[Alexandre Oliva <aoliva at redhat dot com>]

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

> However, before I
> consider applying it, I have a question: why don't we bother adjusting
> relocs in gas?

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.

Consider, for example:

.Lfoo:
        ;; code and data taking up 64 bytes
.Lbar:


Consider references to .Lfoo+32 and .Lbar-32.  They should be the
same, right?

What if the code between .Lfoo and .Lfoo+32 is relaxed?  What if
there's something relaxed between .Lbar-32 and .Lbar?  Should they be
adjusted differently?  Or should the constant remain unchanged?

Now on to the most difficult bit: in a PIC jump table, we compute
differences between two symbols in the text segment.  Entries are
differences between a code label and the jump table base address,
that's in the same section, e.g.:


.Ljumptable:
;; ...
        .long .Lcode-.Ljumptable
;; ...
.Lcode:
        

We can't compute the offset in the assembler, because we might do
linker relaxation.  But all the linker gets is a PC-relative
relocation at a certain point, and it has to somehow figure out the
actual code label we get to jump to.

The relocation is originally emitted as:

  PCREL  .Lcode + . - .Ljumptable

since we can't emit such a complex relocation, and the range between
.Ljumptable and . is not relaxable, we can compute that offset and use
that as the addend.

Should we reduce .Lcode to section+offset (+ addend), we'd lose track
of the exact code point we're pointing to, so linker relaxation might
end up adjusting it by the wrong amount.

The only way to get it to work right is to retain the reference symbol
as an anchor.


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?

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.

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