On Nov 12, 2007 11:15 PM, Gabriel Sechan <[EMAIL PROTECTED]> wrote:
>
>
> ----------------------------------------
> > Date: Mon, 12 Nov 2007 22:15:11 -0800
> > From: [EMAIL PROTECTED]
> > To: [email protected]
> > Subject: Re: gcc optimizes out program ID string
> >
> > On Nov 12, 2007 6:18 PM, Andrew Lentvorski wrote:
> >> Carl Lowenstein wrote:
> >>> I don't much like the attitude of the gcc developers. "We don't use
> >>> this ourselves, therefore nobody needs it."
> >>
> >> No, what *you* (and others) have asked for is to special case the
> >> removal of an unused string when optimizing.
> >>
> >> I agree with their decision about this.
> >>
> >> Especially since there exists an attribute (and probably a pragma) to
> >> handle this behavior.
> >
> > Where does one learn that this attribute exists, except by searching
> > the archives of with some assistance from Google?
> > __attribute__((used))
> >
> >> The gcc folks have become increasingly prickly about special casing
> >> behavior that they don't have to because it almost always leads to bugs.
> >
> > Perhaps they have lost track of the principle of least surprise.
> >
>
> I don't think so. I expect unused variables to be optimized out. All of
> them. That's the least surprising thing to do, since they aren't needed.
> Why keep this one special one around, for some odd use case that I don't
> quite get.
Let me try to explain the odd-use case so that you can get it.
One wants to plant a marker inside an object file that can be easily
retrieved to indicate the particular source file that produced that
object file. The same marker should be propagated to the executable
file that may be a combination of several object files.
Until gcc4 this could be done in a simple manner that even I could
remember. There are standard tools to retrieve the marker(s) from the
object file or the executable. They work with standard tools to plant
the original marker in the source file.
Got it yet?
carl
--
carl lowenstein marine physical lab u.c. san diego
[EMAIL PROTECTED]
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
