search for: array_pod_sort

Hi, there are a couple of possible issues around array_pod_sort from STLExtras.h . Firstly, qsort() needs a comparator that returns zero on equal inputs. ConstantIntSortPredicate in SimplifyCFG.cpp (where the sort is being used to bring duplicate values together) fails this requirement. All the others look ok. Secondly, on Windows qsort() needs its callback...

...amp;Asm, > MCDataFragment *F, > const MCSectionData *SD) { > std::vector<ELFRelocationEntry> &Relocs = Relocations[SD]; > - // sort by the r_offset just like gnu as does > - array_pod_sort(Relocs.begin(), Relocs.end()); > + TargetObjectWriter->ReorderRelocs(Asm, Relocs); Please add a comment explaining a bit. Nothing elaborate, just something along the lines of, "Sort the relocation entries. Most targets just sort by r_offset, but some (e.g., MIPS) have additional constr...

...at, overall! - WriteSymbolEntry isn't endianness neutral. I would find it easier to read if Is64Bit weren't the top level branch but was only used where it matters, but that is me. - LLVM style is to use assert(... && "Message to include in the assert"). - Please use array_pod_sort (from ADT/STLExtras.h) instead of std::sort. - WriteSecHdrEntry would be easier to read if it just used WriteWord instead of Is64Bit. - The changes to MCSectionELF shouldn't be needed. These should go in MCSectionData instead, or in private maps if possible. I can give you extra target depe...

...                                              MCDataFragment *F, >>                                                 const MCSectionData *SD) { >>    std::vector<ELFRelocationEntry> &Relocs = Relocations[SD]; >> -  // sort by the r_offset just like gnu as does >> -  array_pod_sort(Relocs.begin(), Relocs.end()); >> +  TargetObjectWriter->ReorderRelocs(Asm, Relocs); > > Please add a comment explaining a bit. Nothing elaborate, just something along the lines of, "Sort the relocation entries. Most targets just sort by r_offset, but some (e.g., MIPS) have addi...

...MCDataFragment *F, >>> const MCSectionData *SD) { >>> std::vector<ELFRelocationEntry> &Relocs = Relocations[SD]; >>> - // sort by the r_offset just like gnu as does >>> - array_pod_sort(Relocs.begin(), Relocs.end()); >>> + TargetObjectWriter->ReorderRelocs(Asm, Relocs); >> >> Please add a comment explaining a bit. Nothing elaborate, just something along the lines of, "Sort the relocation entries. Most targets just sort by r_offset, but some (e.g., MI...

Hi guys, attached are a couple of work in progress patches for ELF support in the MC module. I'm sending this email to gather some general feedback on the code. Applying these patches doesn't get you a fully working llvm-mc that understands ELF; it's just the ground work. I've got a couple more small patches that fixup some places that assume Mach-O object format which I'll

Here is the patch. On Thu, Mar 22, 2012 at 11:11 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Hi Jim, > > Yes, the relocation entries have to be reordered so that the > got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation > table. As a result, relocations can appear in a different order than > the instructions that they're for. > > For

Hi Jim, Yes, the relocation entries have to be reordered so that the got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation table. As a result, relocations can appear in a different order than the instructions that they're for. For example, in this code, the post-RA scheduler inserts an instruction with relocation %got(body_ok) between %got(scope_top) and %lo(scope_top). $ cat