[RFC] [PATCH][AVR] Add linker relaxation support. Fix 64-Bit bootstrap failure

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] [PATCH][AVR] Add linker relaxation support. Fix 64-Bit bootstrap failure

Bjoern Haase
Hi,

The following patch adds support for linker relaxation for the avr port.
The most important issue is to choose the shorter variant of the two call/jump
alternatives if the displacement is sufficiently small.
This small change alone results in up to 3 per cent code size reduction for
the applications I have checked so far. The patch changes gas and bfd.
When working on the patch I have stepped over a 64bit-system bug in gas. This
one is fixed in a separate patch.

BFD:

The method is mainly a cut-and paste from the H8300 approach. Differing from
the situation there, an additional correction for the relocation addend has
been newly written.

In order to avoid problems in the interrupt vectors, these are protected from
relaxing as well as a ".jumptables" section that could be used in the (near)
future.

\begin{offtopic}

This ".jumptables" section is meant to be used for table-jump tables for the
devices with three-byte program counter:
For these devices we will not be happy with 2-byte address tables and
instead of them we could better use 4 bytes for storing a table of complete
22 bit jump instructions that we could jump to by an ijmp instruction.
For doing this we would need to make sure that relaxing does never change
the relative offsets within this section.

\end{offtopic}

It would be helpful if someone could have a look at
elf_avr_relax_delete_bytes.
I took this function from H8300 and it works, but I have no clue what it does
and why it is necessary.

GAS:

In order to make relaxation work, we need to make gas preserve more
relocs than it used to preserve. The issue is that all the relative
instruction
offsets no longer must be calculated at assembly time but at linke time.
For this purpose the patch disables the fixups for all of the program-space
relative relocs.

Because there is no way to find out from the object file itself if it is
suitable for relaxing or not, I consider to be it best to make always the
linker make the fixups. Otherwise we would probably need an additional
tag in the object files that prevents undue use. I think the slightly larger
object files (more relocs than previously) are a small price to pay.

Legal issues:

I presently have a copyright assignment only for gcc. Could someone of the
maintainers please ask the FSF to prepare papers for the other two important
projects, both, binutils and gdb?

Bjoern.


2005-08-03  Bjoern Haase  <[hidden email]>

        * gas/config/tc-avr.c:  include <inttypes.h>
        md_begin: replace typecast to int by typecast to intptr_t
        avr_ldi_expression: ditto.


2005-08-03  Bjoern Haase  <[hidden email]>

        * gas/config/tc-avr.c:  include <inttypes.h>
        md_begin: replace typecast to int by typecast to intptr_t
        avr_ldi_expression: ditto.


2005-08-03  Bjoern Haase  <[hidden email]>

        * gas/config/tc-avr.h
        TC_VALIDATE_FIX: Add. disable fixups for progmem related relocs.

        * bfd/elf32-avr.c
        elf32_avr_relax_section: add.
        elf32_avr_relax_delete_bytes: add.
        elf32_avr_get_relocated_section_contents: add.

gas_64bit.patch (3K) Download Attachment
relax_avr.patch (26K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] [PATCH][AVR] Add linker relaxation support. Fix 64-Bit bootstrap failure

Nick Clifton
Hi Bj?rn,

> It would be helpful if someone could have a look at
> elf_avr_relax_delete_bytes.
> I took this function from H8300 and it works, but I have no clue what it does
> and why it is necessary.

It removes a sequence of bytes from inside a particular section.  It is
needed because when a section is shrunk like this, it is not just a
simple case of calling memmove() to shift the bytes about in memory.  It
is also necessary to adjust any reloc which is pointing into the section
  into the area where the bytes are being moved.  Otherwise the relocs
will be left with invalid offsets.

> Legal issues:
> I presently have a copyright assignment only for gcc. Could someone of the
> maintainers please ask the FSF to prepare papers for the other two important
> projects, both, binutils and gdb?

Actually this is up to you.  You need to send a filled out form
requesting a copyright assignment for these particular projects.  I am
attaching the form so that you can fill it out.  Once that is done and
the (binutils) assignment is in place, I will be happy to accept the patch.

Cheers
   Nick

---------------------------------------------------------------------------

request-assign.future:

Please email the following information to [hidden email], and we
will send you the assignment form for your past and future changes.
Please use your full name as the subject line of the message.


[What is the name of the program or package you're contributing to?]


[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]


[For the copyright registration, what country are you a citizen of?]


[What year were you born?]


[Please write your email address here.]


[Please write your snail address here.]





[Which files have you changed so far, and which new files have you written
so far?]





---------------------------------------------------------------------------