[avr-libc-dev] [RFC] Suggestion on how to rapidly implement support for atmega2560-2561

[Björn Haase]

Bernd Trog wrote on Montag, 19. September 2005 17:35 :
> --- Björn Haase <address@hidden> wrote:
> > Positive side-effect would also be that with -ffunction-sections unused
> > functions that are not declared static could be removed by the linker.
>
> IIRC, you need some KEEP() statements for .vectors.
>
> See
> http://savannah.nongnu.org/patch/?func=detailitem&item_id=3593
> for details.

Considering the remarks so far concerning the large devices, I'd like to 
suggest to use the following solution:

1.) Patch the binutils such that the KEEP() directives as suggested in 
http://savannah.nongnu.org/patch/?func=detailitem&item_id=3593 are included. 
I'd like to suggest to add immediately after the progmem data section one new 
entry for a .jumpstub section.
2.) Add "bfd_mach_avr6" in the binutils/bfd directory.
3.) At the same time add support for an avr6 class to the linker and the 
assembler. This probably requires only adding a AVR_ISA_M256 define symbol in 
"binutils/include/opcode/avr.h" and an entry for the new controllers in 
gas/config/tc-avr.c.

4.) In the compiler itself we could consider the jump stub to be a part of the 
more complex function label. So we could insert it as text by modifying the 
definition of the ASM_DECLARE_FUNCTION_NAME. I'd suggest to place the 
function entry label in a section named .jumpstub.function_name so that the 
linker could throw away unused stubs when the appropriate linker switches are 
used. I'd like to make the name of the section for the jump stub *not* depend 
on the -ffunction-sections switch. For the rest I'd use the approach sketched 
in the patch I just had posted (i.e. change the call insn such that it always 
uses the label in the upper memory region).

5.) One would finally need to change the build system for avr-libc such that 
it also generates a lib for the family avr6 and that includes the header 
files.

Drawback of this approach is that we would not be able to optimize away the 
jump stubs in case that we are a) doing an indirect jump to a target function 
that b) itself resides in the lower 128k. For this case we would not need a 
jump stub at all. IMO, this would not be a catastrophe.

In case that we could agree on the procedure above, myself I'd like to offer 
to implement step 4.).  I'm anyway working on the prologue sequence while 
switching from text prologue/epilogue to RTL and 4.) seems to be a small 
addition to this change: For implementing the prologue/epilogue support, I 
anyway had already included special treatments for different pc sizes. So 
what I'd prepare would be a combined patch including both changes.


I don't have a copyright assignment for the binutils unfortunately, and it is 
my experience that getting the FSF paperwork done takes about 4 months. In my 
opinion the work to be done on the binutils is not very large. We possibly 
could ask Marek to implement the necessary small changes on the side of the 
binutils.


For the tedious work of preparing the header files for avr-libc I think that 
it would probably be best to ask someone that really would like to work with 
one of the big devices. :-) 

Yours,

Bjoern