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

[Tristan Gingold <gingold at adacore dot com>]

On Jan 3, 2012, at 12:08 PM, Iain Sandoe wrote:

> Hi Tristan,
> 
> I've amended and applied (together with its tests) with the additional comments as below.
> 
> Note that I updated the (c) years in the altered files, but I did NOT rotate the ChangeLogs.
> 
> Iain
> 
> On 2 Jan 2012, at 11:13, Tristan Gingold wrote:
>> 
>> Ok with the suggested changes (mostly stylistic).  Bracketed points are not required to be addressed for the commit.
>>> +
>>> +      if ((s->n_type & BFD_MACH_O_N_TYPE) == BFD_MACH_O_N_INDR)
>> 
>> [ Maybe we should create a macro to test for indirect symbols ]
> 
> done.
> 
>>> +	/* 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.

Iain,

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.

Tristan.