search for: x86asmbackend

Daniel somehow replied to one of my previous commits on llvm-commits instead of this thread. On Mon, Jul 26, 2010 at 12:41 AM, Daniel Dunbar <daniel at zuster.org> wrote: > Hi Michael, > > Two minor notes: > -- >> diff --git a/lib/Target/X86/X86AsmBackend.cpp b/lib/Target/X86/X86AsmBackend.cpp >> index 2cf65c1..02ac2be 100644 >> --- a/lib/Target/X86/X86AsmBackend.cpp >> +++ b/lib/Target/X86/X86AsmBackend.cpp >> @@ -14,6 +14,7 @@ >>  #include "llvm/MC/MCAssembler.h" >>  #include "llvm/MC/MCExpr.h&quo...

...crosoft VirtualBox - see https://bbs.archlinux.org/viewtopic.php?pid=775414 k6, k6-2, k6-3, winchip-c6, winchip2 - these are 586-class CPUs via c3 c3-2 - see https://bugs.archlinux.org/task/19733 as a proof that Via c3 and c3-Nehemiah don't have nopl Mikulas --- lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) Index: llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp =================================================================== --- llvm.orig/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp 2013-11-03 00:24:20.000000000 +0100 +++ llvm/li...

...aniel somehow replied to one of my previous commits on llvm-commits > instead of this thread. > > On Mon, Jul 26, 2010 at 12:41 AM, Daniel Dunbar <daniel at zuster.org> wrote: >> Hi Michael, >> >> Two minor notes: >> -- >>> diff --git a/lib/Target/X86/X86AsmBackend.cpp b/lib/Target/X86/X86AsmBackend.cpp >>> index 2cf65c1..02ac2be 100644 >>> --- a/lib/Target/X86/X86AsmBackend.cpp >>> +++ b/lib/Target/X86/X86AsmBackend.cpp >>> @@ -14,6 +14,7 @@ >>>  #include "llvm/MC/MCAssembler.h" >>>  #include &q...

...ux.org/viewtopic.php?pid=775414 > k6, k6-2, k6-3, winchip-c6, winchip2 - these are 586-class CPUs > via c3 c3-2 - see https://bugs.archlinux.org/task/19733 as a proof that > Via c3 and c3-Nehemiah don't have nopl > > Mikulas > > --- > lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > Index: llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp > =================================================================== > --- llvm.orig/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp 2013-11-03 00:24:20...

...my previous commits on llvm-commits >> instead of this thread. >> >> On Mon, Jul 26, 2010 at 12:41 AM, Daniel Dunbar <daniel at zuster.org> wrote: >>> Hi Michael, >>> >>> Two minor notes: >>> -- >>>> diff --git a/lib/Target/X86/X86AsmBackend.cpp b/lib/Target/X86/X86AsmBackend.cpp >>>> index 2cf65c1..02ac2be 100644 >>>> --- a/lib/Target/X86/X86AsmBackend.cpp >>>> +++ b/lib/Target/X86/X86AsmBackend.cpp >>>> @@ -14,6 +14,7 @@ >>>>  #include "llvm/MC/MCAssembler.h" >&...

...Mon, Jul 26, 2010 at 12:04 PM, Aaron Gray <aaronngray.lists at gmail.com> > wrote: > > You probably want to add Cygwin and MinGW32 Triples as well :- > > case Triple::Win32: > > + case Triple::Cygwin: > > + case Triple::MinGW32: > > return new WindowsX86AsmBackend (T); > > Aaron > > Can someone test this on those platforms? That change would effect > quite a few people. It should not have any side effects as object emission is not used on these platforms and only if enabled. Also ELF which is the default, which is not used on these platform...

On Mon, Jul 26, 2010 at 12:04 PM, Aaron Gray <aaronngray.lists at gmail.com> wrote: > You probably want to add Cygwin and MinGW32 Triples as well :- >    case Triple::Win32: > +  case Triple::Cygwin: > +  case Triple::MinGW32: >      return new WindowsX86AsmBackend (T); > Aaron Can someone test this on those platforms? That change would effect quite a few people. - Michael Spencer

...its >>> instead of this thread. >>> >>> On Mon, Jul 26, 2010 at 12:41 AM, Daniel Dunbar <daniel at zuster.org> wrote: >>>> Hi Michael, >>>> >>>> Two minor notes: >>>> -- >>>>> diff --git a/lib/Target/X86/X86AsmBackend.cpp b/lib/Target/X86/X86AsmBackend.cpp >>>>> index 2cf65c1..02ac2be 100644 >>>>> --- a/lib/Target/X86/X86AsmBackend.cpp >>>>> +++ b/lib/Target/X86/X86AsmBackend.cpp >>>>> @@ -14,6 +14,7 @@ >>>>>  #include "llvm/MC/MCAss...

...; k6, k6-2, k6-3, winchip-c6, winchip2 - these are 586-class CPUs > > via c3 c3-2 - see https://bugs.archlinux.org/task/19733 as a proof that > > Via c3 and c3-Nehemiah don't have nopl > > > > Mikulas > > > > --- > > lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > Index: llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp > > =================================================================== > > --- llvm.orig/lib/Target/X86/MCTargetDesc/X86AsmBackend.cp...

...which can go > back and re-emit the instruction in 32-bit mode if it finds it doesn't > fit? > > Do we just need to support a similar fixup for promoting 16-bit to > 32-bit relocations? OK, the term I was looking for was 'relaxation'. Look in lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp for X86AsmBackend::relaxInstruction() and related methods. Observe that it will cope with 'relaxing' 8-bit PC-relative relocations to 32-bit PC-relative, but it doesn't cope with anything else. Your task, should you choose to accept it, is to make it cope with other forms of relax...

This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 It also fixes a test which was requiring the *wrong* output. I'm relatively happy with this part, and it even solves most of the hard part of feature request for .code16 in bug 8684 — which was actually why I started prodding at this. But I could do with some help with the 16-bit signed relocation handling, which I've

...iter * createWinCOFFObjectWriter > (raw_ostream & OS); } > > If you need a function to be visible across files, use a header; > shortcuts like this make the code more difficult to read. > > On this one, it didn't seem appropriate to include WinCOFFObjectWriters header into X86AsmBackend, it also seems to be overkill to add a header to contain a single function. I would like some more feedback on what the sanctioned course of action should be here. - Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/...

On 20.02.2015 16:38, David Woodhouse wrote: > On Fri, 2015-02-20 at 15:58 +0100, Vladimir 'φ-coder/phcoder' Serbinenko > wrote: >> When experimenting with compiling GRUB2 with clang using integrated as, >> I found out that it generates a 16-bit code bigger than gas counterpart >> and result gets too big for size constraints of bootsector. This was >> traced

...ion pass. An example here is the x86 jmp instruction: the choice between near and long jumps (and hence 2 bytes or 5 bytes on x86-64) is not made until the actual conversion to MCInst and after applying all of the fixups--which only happens deep within the bowels of the AsmPrinter pass. Right. See X86AsmBackend::mayNeedRelaxation() and friends for the gory details. -jim > > -- > Joshua Cranmer > News submodule owner > DXR coauthor > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >...

...y in TargetAsmBackend::createObjectWriter. This allows backend specific stuff in lib/MC/ELFObjectWriter.cpp to be moved to the backend's directory. There are obviously several things that could be done differently: 1. The backend specific ELFObjectWriter classes are declared and implemented in X86AsmBackend.cpp and ARMAsmBackend.cpp; it may be better to put these classes in their own files. 2. The ELFObjectWriter base class is declared in llvm/MC/MCObjectWriter.h; it may be better to put this declaration in its own header file. 3. Some of the flags, such as Is64Bit and EMachine, could be virtual met...

...stream & OS); } >> >>>>If you need a function to be visible across files, use a header; >>>>shortcuts like this make the code more difficult to read. >> >> > >On this one, it didn't seem appropriate to include WinCOFFObjectWriters header into X86AsmBackend, it also seems to be overkill to add a header to contain a single function. I would like some more feedback on what the sanctioned course of action should be here. > >- Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/p...

Owen, On 11/29/12 18:16, Owen Anderson wrote: >> Will the size of the >> packet be properly accounted for by the MCObjectStreamer if we have to pad >> the packet (mainly for fetch alignment)? > The MC system (including relaxation) is capable of handling instructions with variable length encodings whose size can't be determined until the MCCodeEmitter step. Where could I

On 10/23/2012 1:58 PM, John Criswell wrote: > Dear All, > > I'm enhancing a MachineFunctionPass that enforces control-flow > integrity. One of the things I want to do is to set the alignment of > an instruction (by adding NOPs before it in the MachineBasicBlock or > by emitting an alignment directive to the assembler) if it causes a > specific sequence of bytes to be

On Wed, May 19, 2010 at 10:31 PM, Nathan Jeffords <blunted2night at gmail.com> wrote: > Hi guys, > I have attached my patch to support generating win32 COFF object files. I > would have posted earlier, but my system drive crashed and I had to rebuild > my system; Luckily, my source code was on a secondary drive. I think this > would be a good beginning for ongoing support of

Dear All, I'm enhancing a MachineFunctionPass that enforces control-flow integrity. One of the things I want to do is to set the alignment of an instruction (by adding NOPs before it in the MachineBasicBlock or by emitting an alignment directive to the assembler) if it causes a specific sequence of bytes to be generated at a specific alignment. The goal is to ensure that sequences of