This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
dynamic linking.

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.

-cary


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]