avr-libc-dev
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]