[Patch mach-o, indirect symbols 1/2] support indirect symbols in mach-o.
Iain Sandoe
developer@sandoe-acoustics.co.uk
Wed Jan 4 09:14:00 GMT 2012
Hi Tristan,
On 4 Jan 2012, at 08:26, Tristan Gingold wrote:
>>> 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...
>>
>> So, here's a revised patch -
>> that uses (BSF_INDIRECT | BSF_SYNTHETIC) as the 'signal' from gas -
>> > bfd that the symbol is a mach_o .indirect_symbol
>> these symbols are also unnamed (could be used as a third key if
>> there is a meaning - can't think of one tonight - to (BSF_INDIRECT
>> | BSF_SYNTHETIC)).
>
> I think we should really moving .indirect_symbols out of the symtab
> for the following reasons:
> 1) there is no natural flags for them (BSF_INDIRECT | BSF_SYNTHETIC
> is not fully correct)
> 2) they are anonymous (so it doesn't make sense to create a symbol
> for them)
> 3) they aren't physically in the symtab
> 4) they're values are well defined.
> 5) there is a symmetry violation: when we read a mach-o file, we
> don't create symbol for .indirect_symbol, but we will need symbols
> to create .indirect_symbol. This will lead to trouble for objcopy
> and co.
> If you don't agree, please argue!
Those seem good reasons to me too.
So .. what about a new obstack for these in obj-macho.c?
and, I suppose, a private interface for passing them to BFD.
===
I'll repost the symbol quals patch if you like - since there's quite a
lot to remove (or are you OK with me removing and applying?)
>> + do
>> + {
>> + name = input_line_pointer;
>> + c = get_symbol_end ();
>> + symbolP = symbol_find_or_make (name);
>> + err = obj_mach_o_set_symbol_qualifier (symbolP, ntype);
>> + *input_line_pointer = c;
>> + if (err)
>> + break;
>
> Do we need to break in case of error ?
... I'm not a fan of a flurry of errors for one typo ..
(but I suppose we should also do an 'ignore_rest_of_Line' as well)
I'll remove it for now, and we can see how that works out.
thanks for reviewing!
Iain
More information about the Binutils
mailing list