> From: James E Wilson <[EMAIL PROTECTED]>
> Date: Fri, 11 Mar 2005 17:52:03 -0800
> On Fri, 2005-03-11 at 08:12, Hans-Peter Nilsson wrote:
> > I don't really understand what you mean: if a thing is called
> > "foo" in the source, then -fglobalize-symbol=foo would work.
>
> My main concern is tha
On Sat, Mar 12, 2005 at 06:30:00PM +0200, Kai Henningsen wrote:
> Anyway, that seems to be very much the wrong tool to me. For stuff like
> thes, you'd really want a tool that understands C, so it can make a
> certain modification for certain syntactical places.
I don't see why. If the source
[EMAIL PROTECTED] (Richard Henderson) wrote on 11.03.05 in <[EMAIL PROTECTED]>:
> On Fri, Mar 11, 2005 at 02:48:35AM +0100, Hans-Peter Nilsson wrote:
> > > Isn't a compiler option -fglobalize-symbol also a form of source-level
> > > instrumentation? Either way, you need the source, and you get d
On Fri, 2005-03-11 at 08:12, Hans-Peter Nilsson wrote:
> I don't really understand what you mean: if a thing is called
> "foo" in the source, then -fglobalize-symbol=foo would work.
My main concern is that we have a long history of adding flawed features
that have to be later removed. So I want y
On Fri, Mar 11, 2005 at 10:30:00AM +0200, Kai Henningsen wrote:
> [EMAIL PROTECTED] (James E Wilson) wrote on 10.03.05 in <[EMAIL PROTECTED]>:
>
> > On Thu, 2005-03-10 at 17:48, Hans-Peter Nilsson wrote:
> > > This isn't a source-level modification, by definition.
> >
> > And I could argue that m
[EMAIL PROTECTED] (James E Wilson) wrote on 10.03.05 in <[EMAIL PROTECTED]>:
> On Thu, 2005-03-10 at 17:48, Hans-Peter Nilsson wrote:
> > This isn't a source-level modification, by definition.
>
> And I could argue that my suggestion isn't a source-level modification
> either, or I could argue th
> From: James E Wilson <[EMAIL PROTECTED]>
> Date: Thu, 10 Mar 2005 21:51:12 -0800
> On Thu, 2005-03-10 at 20:14, Hans-Peter Nilsson wrote:
> > That question isn't applicable or maybe I should say "by
> > identity mapping". To wit, SYMNAME refers to whatever has
> > "static" in front of it *in th
On Fri, Mar 11, 2005 at 02:48:35AM +0100, Hans-Peter Nilsson wrote:
> > Isn't a compiler option -fglobalize-symbol also a form of source-level
> > instrumentation? Either way, you need the source, and you get different
> > code emitted.
>
> This isn't a source-level modification, by definition.
On Thu, 2005-03-10 at 20:14, Hans-Peter Nilsson wrote:
> That question isn't applicable or maybe I should say "by
> identity mapping". To wit, SYMNAME refers to whatever has
> "static" in front of it *in the source code*, but for which you
> want it removed, i.e. globalized (speaking in C terms).
> From: James E Wilson <[EMAIL PROTECTED]>
> Date: Thu, 10 Mar 2005 19:34:01 -0800
> On Thu, 2005-03-10 at 17:48, Hans-Peter Nilsson wrote:
> > Of course! The simple (and best) way out is to define what
> > happens in all those situations as the equivalent of removing
> > "static" for such an ide
On Thu, 2005-03-10 at 17:48, Hans-Peter Nilsson wrote:
> This isn't a source-level modification, by definition.
And I could argue that my suggestion isn't a source-level modification
either, or I could argue that your suggestion really is a source-level
modification, but it seems pointless to argu
> Date: Thu, 10 Mar 2005 17:36:37 -0800
> On Thu, 2005-03-10 at 16:55, Hans-Peter Nilsson wrote:
> > But that requires source-level instrumentation.
>
> Isn't a compiler option -fglobalize-symbol also a form of source-level
> instrumentation? Either way, you need the source, and you get differen
On Thu, 2005-03-10 at 16:55, Hans-Peter Nilsson wrote:
> But that requires source-level instrumentation.
Isn't a compiler option -fglobalize-symbol also a form of source-level
instrumentation? Either way, you need the source, and you get different
code emitted.
If you are interested in implement
> Date: Thu, 10 Mar 2005 14:41:23 -0800
> From: James E Wilson <[EMAIL PROTECTED]>
> Fredrik Hugosson wrote:
> > My proposal is the following new options:
> > -fglobalize-symbol=SYMBOLNAME
> > -fglobalize-symbols=FILENAME
> > -fglobalize-all-symbols
>
> It is unlikely someone will volunteer to im
Fredrik Hugosson wrote:
My proposal is the following new options:
-fglobalize-symbol=SYMBOLNAME
-fglobalize-symbols=FILENAME
-fglobalize-all-symbols
It is unlikely someone will volunteer to implement a feature that only
you need.
Globalizing a symbol in a shared library is potentially unsafe, and
Hi!
When working with unit tests I frequently have the need to override a
function or variable in a shared library. This works just as I want for
global symbols, but if the symbol is local (declared static) I have to
modify the source (remove the static using a STATIC preprocessor define)
to ma
16 matches
Mail list logo
