Re: simulating section-gc with ar-archives?

[Ian Lance Taylor <ian at airs dot com>]

Adam Megacz <adam@megacz.com> writes:

> Ian Lance Taylor <ian@airs.com> writes:
> > > one section to a static variable in another section be handled by a
> > > reloc with the symbol name of the static variable?
> 
> > By file static variable, I mean something like `static int i;'.  Such
> > a symbol has no externally visible name--it can not have an externally
> > visible name, because there is no way to ensure that name is unique
> > across an entire program.  Without an externally visible name, there
> > is no way to resolve a reference from one .o file to another.
> 
> Interesting. My understanding of UNIX binary formats isn't too
> great. I thought that if a function in one section accessed a global
> variable in another section, that the compiler would have to concoct a
> symbol name for the variable, and emit a relocation for the
> function. If this isn't the case, how do functions refer to variables
> in other sections? AFAIK a simple offset wouldn't work since sections
> can be reordered in the final executable, right?

There are two ways to handle this case.  One is to create a local name
for the symbol which is not externally visible.  The other is to emit
a relocation relative to the section itself.  Which technique is used
depends mostly on the object file format.  In gas, relocations are
changed from symbol to section in adjust_reloc_syms in write.c, under
control of the target dependent tc_fix_adjustable macro.  Both
techniques work within a single object file, but do not work across
different object files.

> Anyways, if everything above is correct, and I used both
> -ffunction-sections and -fdata-sections, I would get made-up symbol
> names for all my globals, and relocations for any functions that
> accessed the globals, right? If this is the case, would splitting the
> .o's by section and then linking them back together work?

Well, first, it is not correct.  Second, it wouldn't work because
different .o files would use the same made-up symbol names, so the
linker would not know which made-up symbol name to use for a
particular relocation.

Ian