search for: mcsection

...s namespace)::RewriteSymbols::ID + 40849 6 llc 0x00000001052331bb raise + 27 7 llc 0x0000000105233272 abort + 18 8 llc 0x0000000105233251 __assert_rtn + 129 9 llc 0x0000000104dd593e llvm::cast_retty<llvm::MCSectionMachO, llvm::MCSection*>::ret_type llvm::cast<llvm::MCSectionMachO, llvm::MCSection>(llvm::MCSection*) + 110 10 llc 0x0000000104dcecdb (anonymous namespace)::MCMachOStreamer::ChangeSection(llvm::MCSection*, llvm::MCExpr const*) + 75 11 llc 0x00000...

On Wed, 2010-05-05 at 13:22 -0700, Nathan Jeffords wrote: > > The important point here is that the COFF MCSection needs to > have the right level of semantic information. In fact, > MCSection is the place that I'd start for COFF bringup. > > OK, I see that now. The current isolation > between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has > pr...

...erdata directive is used to declare data that belongs in the language-specific handler's data area. The way it works in GAS is that it creates a pseudo-section containing the data that is later written to the unwind info structure. For LLVM, I suspect I have to do something similar. Trouble is, MCSection doesn't really support any pseudo-sections. It only supports physical sections inside of an object file. Unless someone has a better idea for implementing .seh_handlerdata, I need to extend MCSection to support sections that don't really physically exist, and then add support for writing t...

On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: > Thanks! Funny, I was just preparing a patch to submit for my changes to MCSectionCOFF. My changes look to be fairly independent of yours, my change was to deal with COMDAT's. I had dealt with the characteristics flags in the object writer, but I like this. If you don't mind I would like to merge my changes into this patch and submit it. I was just pondering how to deal w...

Thanks! Funny, I was just preparing a patch to submit for my changes to MCSectionCOFF. My changes look to be fairly independent of yours, my change was to deal with COMDAT's. I had dealt with the characteristics flags in the object writer, but I like this. If you don't mind I would like to merge my changes into this patch and submit it. I was just pondering how to deal w...

...easier; specific instances are included in the comments: -- > diff --git a/lib/MC/WinCOFFStreamer.cpp b/lib/MC/WinCOFFStreamer.cpp > index 1030cdb..079a813 100644 > --- a/lib/MC/WinCOFFStreamer.cpp > +++ b/lib/MC/WinCOFFStreamer.cpp > @@ -18,24 +18,41 @@ > #include "llvm/MC/MCSection.h" > #include "llvm/MC/MCSymbol.h" > #include "llvm/MC/MCExpr.h" > +#include "llvm/MC/MCValue.h" > +#include "llvm/MC/MCAssembler.h" > +#include "llvm/MC/MCAsmLayout.h" > #include "llvm/MC/MCCodeEmitter.h" > #...

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

...tion to place the symbol into. Section assignment really needs to happen at a higher level. The TargetLoweringObjectFile interfaces are the ones responsible for mapping a global/function -> section. This interface (not mcstreamer) should handle this. The important point here is that the COFF MCSection needs to have the right level of semantic information. In fact, MCSection is the place that I'd start for COFF bringup. > instead of SwitchSection, there would be BeginSymbol, and SymbolSymbol, it would > be illegal to call any EmitXXX function outside of these two calls > > Begi...

On Fri, May 7, 2010 at 12:05 AM, Chris Lattner <clattner at apple.com> wrote: > > On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: > > Thanks! Funny, I was just preparing a patch to submit for my changes to > MCSectionCOFF. My changes look to be fairly independent of yours, my change > was to deal with COMDAT's. I had dealt with the characteristics flags in the > object writer, but I like this. If you don't mind I would like to merge my > changes into this patch and submit it. I was just ponderin...

Dear there, I wasn't able to generate obj file for bpf using llc: llc -march bpf -filetype=obj foo.bc Anyone knows what is the missing part in their backend? I want to make it work for my project. Thanks, Xiaochu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150802/e0b55467/attachment.html>

...t; > Section assignment really needs to happen at a higher level. The > TargetLoweringObjectFile interfaces are the ones responsible for mapping a > global/function -> section. This interface (not mcstreamer) should handle > this. > > The important point here is that the COFF MCSection needs to have the right > level of semantic information. In fact, MCSection is the place that I'd > start for COFF bringup. > > OK, I see that now. The current isolation between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has proven somewhat problematic, mostly d...

...Entries() > > + {return Entries.size();} const MCExpr *getEntry(size_t Num) {return > > + Entries[Num];} > > These can be const. > > > > + int64_t ConstantPoolCounter; > > This can be unsigned. > > > > + case AsmToken::Equal: { > > + const MCSection *Section = > > getParser().getStreamer().getCurrentSection().first; > > + assert(Section); > > We should probably check here that the mnemonic is actually 'ldr', e.g. > > see the AsmToken::Identifier case. > > > > +@ RUN: clang -target arm -integrated-...

Hi David, Maybe I’m just blind, but where’s the code to handle the .ltorg directive? Is that a separate patch, maybe? Without that, this is not going to be usable in any circumstance using subsections-via-symbols. +typedef std::map<const MCSection *, ConstantPool> ConstantPoolMapTy; This feels odd to me. Can you elaborate a bit more on the data structure choices?? I would have expected constants to be grouped together explicitly by section and then a nested loop over those sections instead. As-is, won’t this potentially cause lots of swi...

...f a debug flag is set in the app/dev environment which is hosting LLVM). I attempted to do this by adding another AsmPrinter pass to the PassManager, but this runs into all sorts of problems because there's only once MCContext and one MachneModuleInfo pass maintaining various state information (MCSections, MCSymbols, etc.) and the two AsmPrinter passes interfere with each other. The only way I've been able to get this to work is to create an entirely separate PassManager, and use addPassesToEmitFile() on it, which will redo the entire CodeGen process again unnecessarily. Does anyone have any i...

...t of ways than dealing with the compiler! > > Yes somewhat. Currently, the COFF implementation of the assembler backend should maintain a DenseMap from MCSymbol* to whatever data you need to associate with a symbol. This is equivalent to embedding per-symbol stuff in the MCSymbol itself. MCSection should be subclassed and you should put COFF specific stuff in MCSectionCOFF. > >> > > I think this is an important detail I was missing. I can already see how this will help with COMDAT sections. Is there any reason for the difference between symbol and section in this respect?...

...mbol into. > > Section assignment really needs to happen at a higher level. The TargetLoweringObjectFile interfaces are the ones responsible for mapping a global/function -> section. This interface (not mcstreamer) should handle this. > > The important point here is that the COFF MCSection needs to have the right level of semantic information. In fact, MCSection is the place that I'd start for COFF bringup. > > OK, I see that now. The current isolation between TargetLoweringObjectFile -> MCStreamer -> MCObjectWriter has proven somewhat problematic, mostly due to my...

...ompiler! >> >> Yes somewhat.  Currently, the COFF implementation of the assembler backend >> should maintain a DenseMap from MCSymbol* to whatever data you need to >> associate with a symbol.  This is equivalent to embedding per-symbol stuff >> in the MCSymbol itself.  MCSection should be subclassed and you should put >> COFF specific stuff in MCSectionCOFF. > > I think this is an important detail I was missing. I can already see how > this will help with COMDAT sections. Is there any reason for the difference > between symbol and section in this respect?...

...t at gmail.com> wrote: > > > On Fri, May 7, 2010 at 12:05 AM, Chris Lattner <clattner at apple.com> wrote: > >> >> On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: >> >> Thanks! Funny, I was just preparing a patch to submit for my changes to >> MCSectionCOFF. My changes look to be fairly independent of yours, my change >> was to deal with COMDAT's. I had dealt with the characteristics flags in the >> object writer, but I like this. If you don't mind I would like to merge my >> changes into this patch and submit it. I was j...

...ifies one section within that ELF file based on the data contained within another section. Using llvm-objdump as a template of how to read an object file, I've been able to read the latter section that tells me what to edit, but I haven't found a way to edit the former, as everything in the MCSection/ELFObjectFile/SectionRef classes seem to be read-only as far as section contents are concerned. The changes I would want to make don't change the size of any section, all I need to do is for example zero the first n bytes of .text whilst keeping the rest of the object the same. What would be t...

...uashed version of all three for easy reading). I believe many of your concerns were addressed. See below for a detailed response. > Maybe I'm just blind, but where's the code to handle the .ltorg directive? It is implemented in patch 0003 in this email. > +typedef std::map<const MCSection *, ConstantPool> ConstantPoolMapTy; > > This feels odd to me. Can you elaborate a bit more on the data structure > choices?? I would have expected constants to be grouped together > explicitly by section and then a nested loop over those sections instead. > As-is, won't this...