This is the mail archive of the
mailing list for the binutils project.
Re: [nonworking patch] gold/arm: define $a/$d markers in .plt
> It already is. ?But, following Cary's advice, I needed to explicitly
> go over the new list in sized_write_globals too. ?I don't entirely
> understand why they are not in the table already as forced_locals_ are
> so as to be caught by the existing loop. ?My new method to create them
> is not doing the bookkeeping that goes on in define_special_symbol,
> which I guess is why. ?But from reading the logic there I can't really
> tell what it ought to do for the case of a new local symbol with the
> same name as a different existing symbol.
The global symbol table is, as its name suggests, for global symbols
-- i.e., symbols that should be unique by name. The reason
forced-local symbols are in the table is because they were global
symbols for static linking, and were turned into local symbols for
The symbols you're adding are truly local -- you don't want them to be
resolved by name, which is why you don't want to go through the other
stuff in define_special_symbol or add them to the global symbol table.
But because they're linker generated, they need to be handled by
write_globals, hence the additional generated_locals_ list.
I think this generated-locals treatment would actually be appropriate
for _GLOBAL_OFFSET_TABLE_, _DYNAMIC, and the other linker-generated
STB_LOCAL symbols, but we get away with adding them to the global
symbol table because their names happen to be unique. That's why I
suggested keying off of the binding in define_in_output_data() rather
than adding a new method to the Symbol_table class.