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

[Iain Sandoe]

On 3 Jan 2012, at 16:31, Iain Sandoe wrote:

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

looking again at the mach-o file format doc, I think I have...

it seems that N_INDR is an alias (wonder why the native as doesn't use  
it?)

===

Well, OK, the simplest solution is to keep the code mechanism as is -  
but to use a new/different flag to signal .indirect_symbols .. the  
sorting etc. doesn't really need to change (just the bits using  
IS_MACHO_INDIRECT - which needs to utilize a different flag) .. any  
suggestions about the Right Flag  (or a new one)?

The GAS end will need amending to use a SET_MACHO_INDIRECT .. but  
that's also not too too bad...

.. WDYT?
Iain