This is the mail archive of the
mailing list for the binutils project.
Re: [Patch mach-o, indirect symbols 1/2] support indirect symbols in mach-o.
On 3 Jan 2012, at 16:17, Tristan Gingold wrote:
+ /* 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
to construct and order the symtab - we need the sections.
to construct the indirect symbol dependent indices - we need the
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.
well, maybe I have too ;-)
-- it's a weird scenario when there's a type that is not actually
emitted - but is recognized.
There are two kinds of indirect symbols:
N_INDR symbols, which cannot be emitted by native as, and appear in
the symbols table
they will not be emitted with the code I've applied [unless you
disable the dysymtab], but intercepted and output
as .indirect_symbols ...
.indirect_symbols, which never appear in the symbol table but only
in the indirect symbols table.
... because I've used N_INDR as an intermediate representation for
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
Then we'd have to introduce a new store with most of the properties of
the symbols table, but restricted to .indirect_symbols ... there
doesn't seem to be a particular penalty for using the symbol table (we
could even use it with a zero name, like stabd does, if that would
help -- the sort order is not determined on name).
N_INDR symbols _are_ recognized by the native "nm" ... which led me to
deduce (possibly incorrectly) that the dysymtab way of doing things is
simply a more efficient modern scheme than looking up from the name
(which could be found from the old representation by the value field).
That is why I used N_INDR as an intermediate representation (from GAS).
I guess the alternative is to introduce another field into the symbol
to carry the fact that they are of this type.
+ qsort (symbols, (size_t) nin, sizeof (void *),
[ 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.
.. well, to be compatible with the native tools we also have to sort
undefined and global names into string order.