search for: mcsectiondata

...; > + > WinCOFFStreamer(MCContext &Context, > TargetAsmBackend &TAB, > MCCodeEmitter &CE, > raw_ostream &OS); > > + void OnSectionDataCreated(MCSection const *Section, > + MCSectionData *SectionData); > + > + void OnSymbolDataCreated(MCSymbol const *Symbol, > + MCSymbolData *SymbolData); These aren't used, can you just remove them and add them when they actually are needed? > + MCSectionData *getSectionData(MCSection const *Section = 0...

On Sun, Jul 11, 2010 at 6:10 PM, Chris Lattner <clattner at apple.com> wrote: > This probably needs to be slightly tweaked to work with mainline.  I don't see anything objectionable, but I think Daniel needs to review this one. Updated patch to work with mainline. http://github.com/Bigcheese/llvm-mirror/commit/d19a4c82c18afc4830c09b70f02d162292231c94 - Michael Spencer

...e to fix or if this is an important design decision. The reason for MCSectionCOFF etc., is that they are shared between the MC and CodeGen interfaces. They have semantics that apply to both .s files and object files, and even the frontend has some interest in them. OTOH, things like MCSymbolData, MCSectionData, are private to the assembler backend, and so only the assembler and object writer need to know about them (they are unused when writing to a .s file, for example). MCAssembler already maintains its own association of these data structures, and there are a few bits available for the object file ba...

...&& "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 dependent fields if need be. This enforces layering between the parts CodeGen can access and the parts that are private to the assembler backend. On 0003: - Might as well merge this with 0002. On 0004: - This looks good, migh...

On May 5, 2010, at 5:22 PM, Nathan Jeffords wrote: > > The logic to handle this has to go somewhere, putting it in the MCStreamer *implementation* that needs it is the most logical place. We also aim to implement an assembler, it doesn't make sense to duplicate this logic in the compiler and the assembler parser. > > > Assembly language has often been *the* intermediate

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

...in the comment line. +#include <llvm/MC/MCObjectWriter.h> +#include <llvm/ADT/SmallString.h> +#include <llvm/ADT/SmallVector.h> Please use "" style includes for llvm headers. +namespace coff { + + using llvm::raw_ostream; + using llvm::MCSymbolData; + using llvm::MCSectionData; Please don't use 'using' directives in headers. + uint8_t * Ptr = reinterpret_cast <uint8_t *> (Data); + Ptr [0] = (Value & 0x000000FF) >> 0; It would be more consistent to space this sort of thing as: + uint8_t *Ptr = reinterpret_cast<uint8_t *>(D...

Here is a full patch including Nathan's COFF support, tests that pass on Windows, and some changes to lit. Obviously the COFF support and changes to lit should be separate patches in the end. http://codereview.appspot.com/1624043/show - Michael Spencer -------------- next part -------------- A non-text attachment was scrubbed... Name: COFF-support.patch Type: application/octet-stream Size:

...er.h> > +#include <llvm/ADT/SmallString.h> > +#include <llvm/ADT/SmallVector.h> > > Please use "" style includes for llvm headers. > > > > +namespace coff { > + > + using llvm::raw_ostream; > + using llvm::MCSymbolData; > + using llvm::MCSectionData; > > Please don't use 'using' directives in headers. > > > > + uint8_t * Ptr = reinterpret_cast <uint8_t *> (Data); > + Ptr [0] = (Value & 0x000000FF) >> 0; > > It would be more consistent to space this sort of thing as: > > + u...

Figured it out If I have an MCObjectStreamer object and the MCSection object of the section in question all I need to do is MCObjectStreamer & MCOS = static_cast <MCObjectStreamer &>(OutStreamer); MCSectionData &SD = MCOS.getAssembler().getOrCreateSectionData(*Section); SD.setAlignment(4); Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121218/7be67667/attachment.html>

...locations[Fragment->getParent()].push_back(ERE); > } > > @@ -1072,8 +1048,7 @@ void ELFObjectWriter::WriteRelocationsFragment(const MCAssembler &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...

On Nov 1, 2011, at 6:26 PM, Michael Spencer wrote: > A major feature of the linker design I have been working on is the > object file IR it is based on. It takes the concept of an atom (a > named range of data) and formalizes it into a graph based data > structure where edges represent the relations between atoms such as > relocations, groupings, and layout constraints. This

...ring.h> >> +#include <llvm/ADT/SmallVector.h> >> >> Please use "" style includes for llvm headers. >> >> >> >> +namespace coff { >> + >> + using llvm::raw_ostream; >> + using llvm::MCSymbolData; >> + using llvm::MCSectionData; >> >> Please don't use 'using' directives in headers. >> >> >> >> + uint8_t * Ptr = reinterpret_cast <uint8_t *> (Data); >> + Ptr [0] = (Value & 0x000000FF) >> 0; >> >> It would be more consistent to space thi...

...->getParent()].push_back(ERE); >>  } >> >> @@ -1072,8 +1048,7 @@ void ELFObjectWriter::WriteRelocationsFragment(const MCAssembler &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 e...

...h_back(ERE); >>> } >>> >>> @@ -1072,8 +1048,7 @@ void ELFObjectWriter::WriteRelocationsFragment(const MCAssembler &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); >> >&g...

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

2011/11/1 Jush Lu (盧育龍) <Jush.Lu at mediatek.com>: > Hi all, > > We are developing a linker, MCLinker. > > MCLinker is a linker for LLVM. It leverages the LLVM machine code (MC) layer to link object files and bitcodes, and generate shared objects and executable files. > > > Motivation > ---------- > > The development of MCLinker was started out of the need

Hi all, We are developing a linker, MCLinker. MCLinker is a linker for LLVM. It leverages the LLVM machine code (MC) layer to link object files and bitcodes, and generate shared objects and executable files. Motivation ---------- The development of MCLinker was started out of the need for an LLVM integrated linker. LLVM lacks an integrated linker; hence, it relies on external linkers to

...nsate for the addend of the symbol address, if it was + // undefined. This occurs with weak definitions, for example. + if (!SD->Symbol->isUndefined()) + FixedValue -= Layout.getSymbolOffset(SD); + } else { + // The index is the section ordinal (1-based). + const MCSectionData &SymSD = + Asm.getSectionData(SD->getSymbol().getSection()); + Index = SymSD.getOrdinal() + 1; + FixedValue += Writer->getSectionAddress(&SymSD); + } + if (IsPCRel) + FixedValue -= Writer->getSectionAddress(Fragment->getParent()); + + // The type...