RFC and PATCH - Defining variables in the linker script without defining them as symbols on the file

Guilherme Destefani gd@helixbrasil.com.br
Thu Jul 8 23:45:00 GMT 2004


On Thu, 2004-07-08 at 14:04, Zack Weinberg wrote:
> Guilherme Destefani <gd@helixbrasil.com.br> writes:
> 
> > This patch add to the linker a command like PROVIDE(var=value), named
> > TEMPORARY(var=value) that can be used to define variables just for
> > temporary use, so those variables won't be sent to the file as a symbol.
> 
> Ooh, nifty.  Would you please investigate adding the ability to set
> these variables from the command line? 
Yes, follows a patch to do it too.
>  The desired semantic is that
> TEMPORARY(var=value) gets overriden by --some-switch var=value, but
> whether or not that happens, /var/ is available for calculation in
> the linker script.  (--defsym symbols can't be used for arbitrary
> calculation.)
While testing if it's working, I found out that if I have a script with
those lines inside SECTIONS{
lixo = lixo_1;
TEMPORARY( lixo_1 = 0x1);
}

I have as result:
make ok;readelf -a ok|grep lixo
cc -Wl,-T -Wl,script -Wl,--deftmp -Wl,lixo1=0x19  -Wl,--deftmp
-Wl,lixo2=0x29    ok.c   -o ok
    49: 00000001     0 NOTYPE  GLOBAL DEFAULT  ABS lixo
    59: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND lixo_1

As you can see, lixo_1 ends up as undefined.
The parser accept the variable, but in the tree used to construct the
sentence lixo = lixo_1; lixo_1 is not defined yet.	Why the parser accept
a variable that wasn't defined yet?

But if the order is inverted, like this:
SECTIONS{
TEMPORARY( lixo_1 = 0x1);
lixo = lixo_1;
}

The result looks just fine:
make ok;readelf -a ok|grep lixo
cc -Wl,-T -Wl,script -Wl,--deftmp -Wl,lixo1=0x19  -Wl,--deftmp
-Wl,lixo2=0x29    ok.c   -o ok
    49: 00000001     0 NOTYPE  GLOBAL DEFAULT  ABS lixo

Why the order of declaration/use force the symbol to be undefined?
The tree isn't evaluated just when needed?

It is OK to left a small amount of memory allocated, like this patch and
the lang_memory_region_list does?
> zw
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: binutils-2.15.90.0.3-temporary.patch
Type: text/x-patch
Size: 14744 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20040708/756d5433/attachment.bin>


More information about the Binutils mailing list