similar to: Fwd: X86 assembler cannot jump NEAR?

On Feb 28, 2016 12:08 AM, "Stephen Checkoway" <s at pahtak.org> wrote: > > > > > On Feb 27, 2016, at 4:36 AM, Jun Koi via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > The problem is that llvm-mc always compiles "jmp" this as short jump, no matter where the target is. Hence my question. I dont know if there is any way to change this

Hi, Currently X86 assembler seems to always compile "jmp _label" as a SHORT jump with "EB" opcode: $ echo "jmp _label"|llvm-mc -assemble -triple=i386 -show-encoding .text jmp _label # encoding: [0xeb,A] My question is: can X86 assembler supports NEAR jump with opcode "E9"? I try with "near" keyword, but it is not

I think this is really because the assembler doesn't run layout and relaxation when not dumping to an object file. I disassembled an object file with this same test case and got e9 00 00 00 00. On Fri, Feb 26, 2016 at 9:00 PM, Jun Koi via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > Currently X86 assembler seems to always compile "jmp _label" as a SHORT

Is there any reason to prefer a NEAR jump to a SHORT jump if the assembler deemed it is okay to keep it as a SHORT one? The only reason you may want to have it as a NEAR jump is because you need to alter the target of this jump to another address which may be out of a byte range. Regards On 27/02/2016 06:00:54, Jun Koi via llvm-dev (llvm-dev at lists.llvm.org) wrote: > Hi, > >

Hi Kev, I'm glad to hear llvm-objdump is getting attention. I'm unclear on how much output specialization one could (or should) do for ELF vs. Mach-O. If you're game, let's compare an example: $ cat labeltest.s .text foo: nop bar: bum: nop jmp bar jmp bum jmp baz nop baz: nop Assembling for x86 and llvm-objdump'ing, i get $ llvm-mc

In creating a test case for a bug fix in llvm-objdump, I noticed that it differs in its output of pc-relative immediates from objdump: [secdev:/tmp] s$ cat a.s main: jmp .LBL0 .LBL0: ret [secdev:/tmp] s$ llvm-mc -filetype=obj a.s > a.o [secdev:/tmp] s$ objdump -d a.o |tail -n 2 0: eb 00 jmp 2 <main+0x2> 2: c3 retq

Hi, I am trying to undertand which code in LLVM patches the fixups generated by assembler. Here is what I am doing: I use "llvm-mc" to compile X86 assembly code, like below: $ echo "jmp 5000" | ./bin/llvm-mc -assemble -triple=i386 -show-encoding -x86-asm-syntax=att -output-asm-variant=1 .text jmp 5000 # encoding: [0xeb,A]

> On Jan 4, 2018, at 04:23, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Sending a note here as this seems likely to be of relatively broad interest. It looks like this is producing code of the following form. call next loop: pause jmp loop next: mov [rsp], r11 ret As I understand it, the busy loop is to cause the speculative execution to be trapped

On Thu, Oct 17, 2013 at 10:55 AM, Stephen Checkoway <s at pahtak.org> wrote: > In creating a test case for a bug fix in llvm-objdump, I noticed that it > differs in its output of pc-relative immediates from objdump: > > [secdev:/tmp] s$ cat a.s > main: > jmp .LBL0 > .LBL0: > ret > [secdev:/tmp] s$ llvm-mc -filetype=obj a.s > a.o >

Hi, LLVM only support primitive type i32 and i64, no i48. The clang translate "C int type" to i32 too. My question is if a cpu is 48 bits register size, how to write the backend for 48 bits register architecture. Can someone help me with this problem? Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL:

Sending a note here as this seems likely to be of relatively broad interest. Thread: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180101/513630.html Review link: https://reviews.llvm.org/D41723# -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180104/78682480/attachment.html>

On Mon, Aug 10, 2020 at 3:34 AM David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > > Thanks, > > On 07/08/2020 23:28, Kees Cook wrote: > > On Fri, Aug 7, 2020 at 1:18 AM David Chisnall > > <David.Chisnall at cl.cam.ac.uk> wrote: > >> I think it would be useful for the discussion to have a clear threat model that this intends to defend against and

On Sep 5, 2013, at 3:37 AM, gamma_chen <gamma_chen at yahoo.com.tw> wrote: > LLVM only support primitive type i32 and i64, no i48. The clang translate "C int type" to i32 too. My question is if a cpu is 48 bits register size, how to write the backend for 48 bits register architecture. Can someone help me with this problem? I'm not LLVM expert, but I'm pretty sure your

On Thu, Jun 26, 2014 at 10:23 AM, Adam Nemet <anemet at apple.com> wrote: > > > On Jun 25, 2014, at 7:05 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > > > > > On Thu, Jun 26, 2014 at 5:47 AM, Adam Nemet <anemet at apple.com> wrote: > >> Hi Jun, >> >> On Jun 25, 2014, at 8:14 AM, Jun Koi <junkoi2004 at gmail.com> wrote: >>

hi, at the moment, TEST instruction is defined with 0xf7 opcode, as demonstrated below. $ echo "0xf7 0xc0 0x00 0x00 0x00 0x22"|./Release+Asserts/bin/llvm-mc -disassemble -arch=x86 .section __TEXT,__text,regular,pure_instructions testl $570425344, %eax ## imm = 0x22000000 however, i cannot find anywhere this F7 opcode is defined in

On Thu, Jun 26, 2014 at 5:47 AM, Adam Nemet <anemet at apple.com> wrote: > Hi Jun, > > On Jun 25, 2014, at 8:14 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > > > Hi, > > > > I am trying to assemble below instruction with latest LLVM code, but > fail. Am I doing something wrong, or is this a bug? > > > > > > $ echo "vaddps zmm7

The IMM3/IMM5 come from here X86RecognizableInstr.cpp 943 TYPE("SSECC", TYPE_IMM3) 944: TYPE("AVXCC", TYPE_IMM5) On Thu, Dec 25, 2014 at 8:22 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > > > On Fri, Dec 26, 2014 at 11:54 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > >> hi, >> >> some instructions

On Thu, Jan 4, 2018 at 12:31 PM Stephen Checkoway via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Jan 4, 2018, at 04:23, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Sending a note here as this seems likely to be of relatively broad > interest. > > It looks like this is producing code of the following form.

Hi, I found a mismatch between assembler & disassembler of X86: I assembled an instruction, then disassembled the output, but the result is not the same as the first original code: "add qword ptr [205163983024656], 1" vs " add qword ptr [1985229328], 1" Anybody knows what is wrong? Thanks. $ echo "ADD QWORD PTR [0xba9876543210], 0x1"|llvm-mc -assemble

On Mon, May 23, 2016 at 2:44 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > Hi, > > I found a mismatch between assembler & disassembler of X86: I assembled an > instruction, then disassembled the output, but the result is not the same > as the first original code: "add qword ptr [205163983024656], 1" vs " add > qword ptr [1985229328], 1" > >