Displaying 3 results from an estimated 3 matches for "getcurrentfrag".
2010 Oct 23
0
[LLVMdev] Fwd: [llvm-commits] Fwd: Proof of concept patch for unifying the .s/ELF emission of .ARM.attributes
...now.
*) We don't currently use any string attributes, so I did not implement them.
*) Having an attribute emitter class is a nice way to separate the job
of creating the attributes and the decisions of what attributes to
use.
*) The best way I could find of avoiding code duplication was to make
getCurrentFragment and getOrCreateDataFragment public. If they must
really be protected we can then create a special ARM streamer that has
the same functionality as the attribute emitter in this patch. Yet
another option is adding a method for writing over old data in the
streamer API.
*) I added support for mult...
2010 Oct 22
1
[LLVMdev] Fwd: [llvm-commits] Fwd: Proof of concept patch for unifying the .s/ELF emission of .ARM.attributes
---------- Forwarded message ----------
From: Jason Kim <jasonwkim at google.com>
Date: Fri, Oct 22, 2010 at 12:59 PM
Subject: Re: [llvm-commits] Fwd: Proof of concept patch for unifying
the .s/ELF emission of .ARM.attributes
To: Rafael Espíndola <rafael.espindola at gmail.com>
On Fri, Oct 22, 2010 at 12:51 PM, Jason Kim <jasonwkim at google.com> wrote:
> On Thu, Oct 21,
2010 Oct 21
5
[LLVMdev] [llvm-commits] Fwd: Proof of concept patch for unifying the .s/ELF emission of .ARM.attributes
> Also what is the preferred method for MC way of setting out subsection
> sizes after the fact? I am guessing I need to use an MCFixup?
> How do I get an MCExpr to evaluate a method for the subsection size?
> Is there an equivalent use in the places using MCFixup?
> Do I need to add a new subclass to MCExpr for doing this?
>
> JimG, can you please comment on the MachO