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] |
+ /* A pointer to the referenced symbol will be stored in the udata + field. Use that to find the string index. */ + s->symbol.value = + ((bfd_mach_o_asymbol *)s->symbol.udata.p)->symbol.udata.i;
[ One issue is that we don't follow the BFD convention for indirect symbols. To be fixed later ]
that's a tricky one - we need the 'normal' symbols ahead of the indirects (so we'd have to swap in and out).
[ One question: does it make sense to output the indirect name here and therefore avoiding taking care of indirect symbols while sorting ? ]
I am not sure I follow the question - we are constrained to do things in a particular order by needing certain dependent information.
to construct and order the symtab - we need the sections.
to construct the indirect symbol dependent indices - we need the symbols sorted.
to construct the indirect symbol *value* we need the string table offset for the dependent symbol (which is only available when the symbol table is written). Note that this is academic when we write a dysymtab - since we don't then write 'bare' indirect symbols. If we do not write the dysymtab - then the 'normal' symbols precede the indirect ones which means that we get the *value* just in time.
I have just realized I misunderstood indirect symbols, simply because that's ambiguous.
There are two kinds of indirect symbols:
N_INDR symbols, which cannot be emitted by native as, and appear in the symbols table
.indirect_symbols, which never appear in the symbol table but only in the indirect symbols table.
I think it would be better not to put .indirect_symbols in the symbol table, that would be clearer. Give me more time to think about that.
[…]
+ qsort (symbols, (size_t) nin, sizeof (void *), bfd_mach_o_cf_symbols);
[ Unfortunately qsort is not stable! ]
indeed, which is why there's a specific sort decider for each type - if you believe I've missed one (or that it's not adequate) then I guess we could switch to merge sort.
I think it is ok, but qsort is simply over-engineering. We simply need to separate local/external/undefined symbols.
cheers Iain
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |