This is the mail archive of the
`binutils@sourceware.org`
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] |

*From*: Tristan Gingold <gingold at adacore dot com>*To*: Iain Sandoe <developer at sandoe-acoustics dot co dot uk>*Cc*: binutils Development <binutils at sourceware dot org>*Date*: Tue, 3 Jan 2012 17:17:03 +0100*Subject*: Re: [Patch mach-o, indirect symbols 1/2] support indirect symbols in mach-o.*References*: <F69A353D-A35D-4728-83C3-A264A7643FCA@sandoe-acoustics.co.uk> <F960B05E-66B7-4E02-98A1-128C30223BE4@adacore.com> <9C173632-9BBB-469C-A9FC-91AD12D54ED1@sandoe-acoustics.co.uk>

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.

**Follow-Ups**:

**References**:**Re: [Patch mach-o, indirect symbols 1/2] support indirect symbols in mach-o.***From:*Tristan Gingold

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

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |