This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Jan 4, 2012, at 10:14 AM, Iain Sandoe wrote:

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

obstack or linked list, it's up to you.

> and, I suppose, a private interface for passing them to BFD.

I think we could add a field to bfd_mach_o_section, like 'asymbol **indirect_symbols;'.  The length will be known from the section size.
mach-o.c will convert that to indirect symbols.

(Just designing while writing).

> ===
> 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?)

I am OK with you removing and applying.

Thank you for the perseverance !

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

It's up to you, as it is a trade-off (and shouldn't be triggered by gcc)!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]