similar to: [LLVMdev] ULEB in MC

On Wed, Sep 26, 2012 at 2:07 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 26 September 2012 01:08, Jan Voung <jvoung at chromium.org> wrote: > > - Forward references will create negative-valued ids (which end up being > > written out as large 32-bit integers, as far as I could tell). > > Can you use an SLEB-like representation? > > It's

On 26 September 2012 01:08, Jan Voung <jvoung at chromium.org> wrote: > - Forward references will create negative-valued ids (which end up being > written out as large 32-bit integers, as far as I could tell). Can you use an SLEB-like representation? It's probably not going to be backwards compatible, but if there isn't an SLEB/ULEB representation in bitcode, I'd say

Hi All, Bruno asked me to write up a short email about the direction we're going with llvm-mc and how it interacts with the object writer stuff. My hope was that .o writing could be basically done without worrying about llvm-mc, but I think we've reached the point where it is useful to talk about how the two will interact in the future. It turns out that I also failed in the

On 26 September 2012 22:08, Jan Voung <jvoung at chromium.org> wrote: > I think most of the instructions operands are encoded as VBR(N) > for some N number of bits, and it seems to me that VBR(8) is like ULEB? > I think that the default N is 6 bits, but I haven't tried tweaking these > parameters. It has a similar purpose, but slightly different. SLEB (the signed version)

On Mar 29, 2011, at 8:44 AM, Renato Golin wrote: > Hi there, > > I've created a bug on llvm: > > http://www.llvm.org/bugs/show_bug.cgi?id=9582 > > Basically, ARM, Thumb and data mapping symbols should have been > exported in the ELF file, so the linker can work correctly. > > I can do the change and create some test cases, but I haven't been > paying

On Sep 29, 2010, at 3:09 PM, Jason Kim wrote: > Hi Everyone, > > I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, > and had some questions. > > Currently, it defines quite a few methods like printAddrMode4Operand > (linked to ARMInstrInfo.td) that currently assume raw text support in > the OutStreamer. Are these methods still supposed to be

Really sorry I missed this. Just found it looking for something else in my inbox. I think we should support this but * We should still err on other identifiers ".cfi_startport bar" is invalid. * If I read the gas documentation correctly, the effect of "simple" is to skip the initial cfi instructions. We should test if that is the case and implement it too. Accepting and

Hi Everyone, I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, and had some questions. Currently, it defines quite a few methods like printAddrMode4Operand (linked to ARMInstrInfo.td) that currently assume raw text support in the OutStreamer. Are these methods still supposed to be invoked in the MC'ized path for assembly output? Is JimG's new MC/.s

On Tue, Nov 15, 2011 at 11:06 AM, Jim Grosbach <grosbach at apple.com> wrote: > > On Nov 15, 2011, at 10:36 AM, Carter, Jack wrote: > >> Jim, >> >> Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data. >> >> The issue I was having was

On Sep 29, 2010, at 4:27 PM, Jason Kim wrote: >> Yes, but surely not by a function explicitly indicated to be for assembly files. I would expect there to be an equivalent function to do what needs done for object files. Perhaps there isn't one (yet) and that's what's leading to the confusion? > > LOL :-) Yes, maybe that's it. Included is a patch w comments that >

Hi David, The way I imagined that we might want to extend the MCStreamer API (this was motivated by DIEData) is by allowing clients to move bytes and fixups into the MC layer. This is the sort of API that I was imagining: void MoveAndEmitFragment(SmallVectorImpl<char> &&Data, SmallVectorImpl<MCFixup> &&Fixups); Note that this mirrors the

Hi everyone, while looking at the ARMAsmPrinter::EmitStartofAsm function, I realized that what looks like singular assembler directives (.eabi_attribute) are in fact shorthand that needs to go in to the .ARM.attributes section in the ELF file. 1. What is the preferred method in MC to jump back to a prior section already defined? (Or is this not supported?) 2. It looks like the

Hi, After your change, EmitCFIStartProcImpl in MCAsmStreamer does not match the signature of the EmitCFIStartProcImpl in MCStreamer and you end up not overriding the original function. One of the places where "virtual void EmitCFIStartProcImpl(MCDwarfFrameInfo &Frame) = 0" would have helped. :) Specifically, adding virtual void EmitCFIStartProcImpl(MCDwarfFrameInfo &Frame)

> On Feb 29, 2016, at 3:18 PM, David Blaikie <dblaikie at gmail.com> wrote: > > Just in case it interests anyone else, I'm playing around with trying to broaden the MCStreamer API to allow for emission of bytes without copying the contents into a local buffer first (either because you already have a buffer, or the bytes are already present in another file, etc) in

> On Feb 29, 2016, at 3:46 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Feb 29, 2016 at 3:36 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > >> On Feb 29, 2016, at 3:18 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> Just in case it

> On Feb 29, 2016, at 3:46 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Feb 29, 2016 at 3:36 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > >> On Feb 29, 2016, at 3:18 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> Just in case it

On Tue, Jul 20, 2010 at 3:41 PM, Olivier Meurant <meurant.olivier at gmail.com> wrote: > New patch taking Eli's comments into account. Comments inline. If you have commit access, I'd fire away. If not, I can. diff --git include/llvm/MC/MCAssembler.h include/llvm/MC/MCAssembler.h index 07ca070..afff96e 100644 --- include/llvm/MC/MCAssembler.h +++ include/llvm/MC/MCAssembler.h

New patch. Thanks for all of your comments ! > Comments inline. If you have commit access, I'd fire away. If not, I can. I don't have commit access, if you find it ok, please commit it. :) Olivier. On Wed, Jul 21, 2010 at 6:56 AM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > On Tue, Jul 20, 2010 at 3:41 PM, Olivier Meurant > <meurant.olivier at gmail.com>

> On Feb 29, 2016, at 4:10 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Feb 29, 2016 at 3:51 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > >> On Feb 29, 2016, at 3:46 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> >> >> On

On Mar 5, 2010, at 3:20 PM, Wayne Anderson wrote: > Hello, > > I'm interested in the status of LLVM-MC. My particular interest is in > generating executables for ARM embedded applications. I assume this > application is not terribly high on the priority list, so I would like > to know how I can contribute. Can someone point me to some > information and/or