[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] [RFC] Patch adding support for atmega2560-2561
From: |
Björn Haase |
Subject: |
Re: [avr-libc-dev] [RFC] Patch adding support for atmega2560-2561 |
Date: |
Mon, 19 Sep 2005 10:34:41 +0200 |
User-agent: |
KMail/1.7.1 |
David Brown wrote on Montag, 19. September 2005 09:53 :
> I'm not too hot on the internals of gcc, but I'm wondering if there is not
> already a mechanism in place for gcc to detect purely internal linkage (by
> which I mean a "static" function whose address is never taken). When a
> function is declared "inline", the compiler has to know whether it must
> also generate an "outline" version as well - if it knows the function is
> "static" and the address is never taken, the "outline" version is not
> generated. Could this also be used to determine if a stub is needed or not?
> If this were possible, then the stub could be avoided by simply declaring
> functions to be "static" if they are not needed externally to the file,
> cutting down the overhead substantially, since the majority of functions
> can be labelled "static". Of course, that requires a bit of discipline on
> the part of the programmer, as they would have to use "static" explicitly
> on all non-extern functions. But that's good practice anyway (and easily
> checked with "-Wmissing-prototypes" ).
Maybe. I however don't know right now how to do that right now. I rather have
looked for a *easy to implement and safe* method. For this reason, e.g., I
also did not implement the jump stubs as RTL but rather as text.
> An alternative idea might be to use individual sections such as
> ".text1_foo" for the stub for function foo(), and make use of the
> "--gc-sections" option in the linker to remove any such section that is not
> used.
> I'm thinking of the same idea as the "-ffunction-sections" switch in
> gcc which can be used with "--gc-sections" to avoid linking in functions
> that are not used. I haven't tried the "-ffunction-sections" switch, and
> don't even know if it is implemented for the avr port, but perhaps the same
> idea can be used.
If the -ffunction-sections is functional, this would probably be the easiest
and best approach.
BTW, I just recognized that one probably will also need to disable or modify
the table jump insn patterns.
Björn
- [avr-libc-dev] [task #3693] Add new devices: mega 640-1280-1281-2560-2561, Anatoly Sokolov, 2005/09/05
- RE: [avr-libc-dev] [task #3693][task #4102] Add new devices: mega640-1280-1281-2560-2561, Darcy Watkins, 2005/09/06
- [avr-libc-dev] [task #3693] Add new devices: mega 640-1280-1281-2560-2561, Anatoly Sokolov, 2005/09/07
- [avr-libc-dev] [task #3693] Add new devices: mega 640-1280-1281-2560-2561, Uwe Fechner, 2005/09/16
- RE: [avr-libc-dev] [task #3693] Add new devices: mega640-1280-1281-2560-2561, Darcy Watkins, 2005/09/16
- Re: [avr-libc-dev] [task #3693] Add new devices: mega640-1280-1281-2560-2561, Björn Haase, 2005/09/18
- [avr-libc-dev] [RFC] Patch adding support for atmega2560-2561, Björn Haase, 2005/09/18
- Re: [avr-libc-dev] [RFC] Patch adding support for atmega2560-2561, David Brown, 2005/09/19
- Re: [avr-libc-dev] [RFC] Patch adding support for atmega2560-2561,
Björn Haase <=
- Re: [avr-libc-dev] [RFC] Patch adding support for atmega2560-2561, Björn Haase, 2005/09/19
- Re: [avr-libc-dev] [RFC] Patch adding support for atmega2560-2561, Bernd Trog, 2005/09/19
- [avr-libc-dev] [RFC] Suggestion on how to rapidly implement support for atmega2560-2561, Björn Haase, 2005/09/19
- Re: [avr-libc-dev] [RFC] Suggestion on how to rapidly implement supportfor atmega2560-2561, Anatoly Sokolov, 2005/09/23
- [avr-libc-dev] Re: [RFC] Patch adding support for atmega2560-2561, Denis Chertykov, 2005/09/22