Static symbols in libgcc

Static symbols in libgcc

[Jeffrey A Law]

I've been reviewing the libgcc discussion re: static variables.

First, yes, this is a significant problem.


Creating a shared libgcc or an additional shared library to
link into executables which contains the static variables isn't
the right thing to do.  We've already been through the pain of
a shared libgcc once; I don't think we want to do it again.

This implies one of a few directions:

  1. Eliminate the need for these static variables.  However,
  considering how they're used I doubt it's possible.

  2. Move them into libstdc++.  Shouldn't this just involve moving
  some functions into libstdc++?  Or to put it another way is
  there some compelling reason to have these functions in libgcc?

  3. Declare them in such a way as to only get one copy; instead of
  a static, can it be a global (yes, there's a namespace pollution
  issue, but it's worth thinking about).   It could even possibly
  be made weak global if that helps.
  How many of these variables do we have?  Maybe put them into a single
  data structure to avoid polluting the namespace any more than is absolutely
  necessary.

  4. Or have a global pointer to a runtime initialized data structure
  which has the stuff we need.  We have the capability to initialize
  stuff at program startup, so it shouldn't be that much of a stretch
  to use it for this purpose.



On the GOT pointer issue; I don't know AIX well, but it seems to me
that we could just put the values we need into our builtin setjmp
frame.  The other possibility is that the value is sitting in the
stack (this is how HPUX works).

Jeff

Re: Static symbols in libgcc

[Alexandre Oliva]

Jeffrey A Law writes:

>   2. Move them into libstdc++.  Shouldn't this just involve moving
>   some functions into libstdc++?  Or to put it another way is
>   there some compelling reason to have these functions in libgcc?

AFAIK, these variables are not exclusively used by the C++ front-end,
so they shouldn't be moved into the C++-specific library.  gcc 2.8.0
was delayed that long in order to move exception handling into the
back-end.

>   3. Declare them in such a way as to only get one copy; instead of
>   a static, can it be a global (yes, there's a namespace pollution
>   issue, but it's worth thinking about).   It could even possibly
>   be made weak global if that helps.

If it's named __gcc_something, it's not an issue, since this name is
reserved, at least in the C language.  Could this be a problem for
other languages?

>   4. Or have a global pointer to a runtime initialized data structure
>   which has the stuff we need.  We have the capability to initialize
>   stuff at program startup, so it shouldn't be that much of a stretch
>   to use it for this purpose.

I don't understand how functions would obtain references to this data
structure.  Wouldn't they need a global symbol or such?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Static symbols in libgcc

[Jeffrey A Law]

  In message < orn2gpejzy.fsf@amazonas.dcc.unicamp.br >you write:
  > Jeffrey A Law writes:
  > 
  > >   2. Move them into libstdc++.  Shouldn't this just involve moving
  > >   some functions into libstdc++?  Or to put it another way is
  > >   there some compelling reason to have these functions in libgcc?
  > 
  > AFAIK, these variables are not exclusively used by the C++ front-end,
  > so they shouldn't be moved into the C++-specific library.  gcc 2.8.0
  > was delayed that long in order to move exception handling into the
  > back-end.
Good point.


  > >   3. Declare them in such a way as to only get one copy; instead of
  > >   a static, can it be a global (yes, there's a namespace pollution
  > >   issue, but it's worth thinking about).   It could even possibly
  > >   be made weak global if that helps.
  > 
  > If it's named __gcc_something, it's not an issue, since this name is
  > reserved, at least in the C language.  Could this be a problem for
  > other languages?
Right. 


  > >   4. Or have a global pointer to a runtime initialized data structure
  > >   which has the stuff we need.  We have the capability to initialize
  > >   stuff at program startup, so it shouldn't be that much of a stretch
  > >   to use it for this purpose.
  > 
  > I don't understand how functions would obtain references to this data
  > structure.  Wouldn't they need a global symbol or such?
Yes, it would be a single global (presumably exported) symbol.


jeff