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

[Tristan Gingold]

On Jan 3, 2012, at 5:31 PM, Iain Sandoe wrote:

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

I think that's wrong.

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

This too.

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

There is no hurry to change this representation, but it may simply not be the best one.  Contrary to symbols, very few data are required for indirect_symbols: just a symbol 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).

No, they are really two different concepts.
On my machine, /System/Library/Frameworks/Kerberos.framework/Kerberos has both.

> That is why I used N_INDR as an intermediate representation (from GAS).

I think this is not correct. (Again, we don't need to fix that now).

> I guess the alternative is to introduce another field into the symbol to carry the fact that they are of this type.

To be discussed.  There are no BFD way to represent .indirect_symbols!

>> […]
>> 
>>>>> +  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.

Ok, I missed that.  Is it documented in Apple doc ?

Thanks,
Tristan.