[PATCH] [MachO] MachOWriter generates bad indirect symbol tables when sections are split
David Fang
fang at csl.cornell.edu
Tue Mar 12 13:31:21 PDT 2013
Daniel,
Some quick questions about your proposed recipe:
>> Ok, here is what I think the right fix is. Instead of creating the
>> IndirectSymBase mapping we use to associate sections with their
>> indirect offset start, in BindIndirectSymbols() we should:
>>
>> 1. Add a simple container struct (lets say MachSectionIndirectSymbols)
>> for tracking the per-section list of indirect symbols. It will keep
>> the list of symbols in the section and the index of the first indirect
>> symbol in the section.
Like a map<section*, vector<indirect_symbol> >?
Instead of keeping track of the first indirect symbol index, could we just
as easily compute the index offsets later during the second pass:
offset = 0;
for each section S (in order)
record offset for section S
[optional] write vector of indirect symbols for S
offset += S.num_indirect_symbols();
end for
I was able to fix the reserve1 field by doing something like this (bug
14636, comments 30-33), but I only later discovered that the indirect
symbols needed to be reordered.
>> 2. Keep a mapping from sections to the above type.
>> 3. Add a SetVector to record the order of the sections that have
>> indirect symbols.
This I understand, I found SetVector and SmallSetVector in ADT.
>> 4. During BindIndirectSymbols() we maintain the above information
>> (populating the MachSectionIndirectSymbols per-section symbol arrays).
BindIndirectSymbols looks like it need not change, because it's already
operating on the assumption of ordered indirect symbols, right?
>> 5. Once we have scanned all the symbols we make another pass over the
>> sections (in the order seen via indirect symbols) and assign the start
>> indices.
as I outlined above (offset = start indices).
>> 6. Update writing of the indirect symbol table to write in the same
>> order as traversed in #5.
>>
>> Does that make sense? It's more work than your patch but it (a) should
>> preserve binary compatibility with 'as' in situations where the
>> indirect symbols don't appear out of order w.r.t. the sections, (b) it
>> makes somewhere more explicit the relationship between sections and
>> their list of symbols being in contiguous order.
>>
>> - Daniel
Will this re-ordering be acceptable to all Mach-O back-ends? x86, ARM,
PPC?
Fang
--
David Fang
http://www.csl.cornell.edu/~fang/
More information about the llvm-commits
mailing list