Bernd Trog wrote on Montag, 19. September 2005 17:35 : > --- Björn Haase <[EMAIL PROTECTED]> 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 _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
