[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] RE: [bug #16411] -fwhole-program optimization deletes
From: |
Björn Haase |
Subject: |
Re: [avr-libc-dev] RE: [bug #16411] -fwhole-program optimization deletes ISRs |
Date: |
Mon, 28 Aug 2006 12:30:54 +0200 |
User-agent: |
KMail/1.7.1 |
Eric Weddington wrote on Donnerstag, 24. August 2006 18:53 :
> > -----Original Message-----
> > From: Joerg Wunsch [mailto:address@hidden
> > Sent: Thursday, August 24, 2006 10:13 AM
> > To: Ned Konz; Levi Harper; Joerg Wunsch; Eric Weddington;
> > address@hidden
> > Subject: [bug #16411] -fwhole-program optimization deletes ISRs
> >
> >
> > Follow-up Comment #5, bug #16411 (project avr-libc):
> >
> > Please mind Björn Haase's latest changes to the linker script
> > templates. He added several KEEP statements there. AFAIK
> > these changes are not yet in binutils 2.17, they only have
> > been added afterwards. (They might be present in his
> > ATmega256x/linker relaxation patch set, I'm not sure.)
The KEEP () directives don't have any influence on the "-fwhole-program"
issue because only the linker will be aware of them. My suggestion would be
to add the "used" attribute expression in the SIGNAL and ISR macros. So there
will no longer be any problem.
> > Still, I'm opposed to "officially support" any of these
> > features unless someone tests every aspect of them, and is
> > also willing to add documentation for them. Otherwise, it
> > will only become a support nightmare.
I have myself used -gc-sections in a mass series product without meeting any
problems. Constructors and Destructors will also work. I have just checked
that. I myself would not vote against "publishing" the existence of linker
garbage collection. It could be quite useful.
> I understand your concern. However, for this one aspect of this bug, I
> think the concern is unfounded.
I agree.
> The original bug report stated:
> "When using the -fwhole-program optimization on an AVR program containing
> an ISR, the optimizer apparently sees the ISR as uncalled and deletes it.
>
> Adding the __attribute__((used)) to the definition of ISR() fixes this."
>
> The GCC documentation for __attribute__((used)) states:
> "This attribute, attached to a function, means that code must be emitted
> for the function even if it appears that the function is not referenced.
> This is useful, for example, when the function is referenced only in inline
> assembly."
>
> Adding __attribute__((used)) to all ISRs (defined in a user application)
> seems to be a reasonable change, regardless of whether -fwhole-program is
> being used or not. The compiler will make sure that the ISR code is
> emitted, even if -fwhole-program would want to kill it because there are no
> direct references to the ISR.
Yes. I agree.
Bjoern.