Re: [Patch mach-o, indirect symbols 1/2] support indirect symbols in mach-o.

[Iain Sandoe <developer at sandoe-acoustics dot co dot uk>]

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

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  
these ...

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

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 *),  
> > > > 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.

.. well, to be compatible with the native tools we also have to sort  
undefined and global names into string order.

cheers
Iain