<div dir="ltr">This shouldn't have parsed. <div><br></div><div>
<span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">movq (%gs), %r14</span> </div><div><br></div><div>
<span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">That's trying to use%gs as a base register which isn't valid. GNU assembler rejects it. And coincidentally llvm-mc started rejecting it on trunk late last week.</span> That's probably why it printed as %ebp.</div><div><br></div><div>I don't know if there is an instruction to read the base of %gs directly. Maybe rdgsbase, but that's only available on Ivy Bridge and later CPUs.. But ussing %gs as part of the memory address for any other instruction is automatically relative to the base of %gs.</div><div><br></div><div>
<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 26, 2018 at 12:57 PM K Jelesnianski <<a href="mailto:kjski@vt.edu">kjski@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Craig,<br>
<br>
Thanks for the help so far. I have rewritten my assembly to comply<br>
with user-land not being able to directly modify the segment registers<br>
%GS/%FS. I used llvm-mc with -show-inst to get the equivalent LLVM<br>
instruction + operands. Now I am working backwards to actually code<br>
this assembly into my MachineFunctionPass and got the easy assembly<br>
implemented, however my more complicated asm is still struggling as I<br>
am still seeing 0x0(%rbp) instead of (%gs) or errors.<br>
Core question here being: how do I properly create BuildMI statements<br>
for assembly dealing with offsets?<br>
-------------------------------------------------------------------------------------------------<br>
Assembly I want to translate:<br>
mov (%gs), %r14 //get value off %GS base addresss<br>
mov %r15, %gs:0x0(%r14) //put value in R15 into R14:(%GS) [ (%GS) + R14 ]<br>
--------------------------------------------------------------------------------------------------<br>
LLVM-MC -show inst gives:<br>
movq (%gs), %r14 # <MCInst #1810 MOV64rm<br>
# <MCOperand Reg:117><br>
# <MCOperand Reg:33><br>
# <MCOperand Imm:1><br>
# <MCOperand Reg:0><br>
# <MCOperand Imm:0><br>
# <MCOperand Reg:0>><br>
movq %r15, %gs:(%r14) # <MCInst #1803 MOV64mr<br>
# <MCOperand Reg:117><br>
# <MCOperand Imm:1><br>
# <MCOperand Reg:0><br>
# <MCOperand Imm:0><br>
# <MCOperand Reg:33><br>
# <MCOperand Reg:118>><br>
-------------------------------------------------------------------------------------------------------<br>
I'll be honest and say I don't really know how to add the operands<br>
properly to BuildMI. I figured out the following so far<br>
MachineInstrBuilder thing = BuildMI(MachineBB, Position in MBB ,<br>
DebugLoc(not sure what this accomplishes), TII->get( X86 instruction I<br>
want), where instruction result goes)<br>
<br>
this has .add(MachineOperand)<br>
.addReg(X86::a reg macro)<br>
.addIMM(a constant like 0x8)<br>
and a few more I dont think apply to me.<br>
<br>
but I am not sure I must follow a specific order? I am assuming yes<br>
and it has something to do with X86InstrInfo.td definitions, but not<br>
sure.<br>
--------------------------------------------------------------------------------------------------------<br>
LLVM C++ code I tried to translate this to:<br>
/* 1 mov (%gs), %r14 */<br>
MachineInstrBuilder e1 =<br>
BuildMI(MBB,MBB.end(),DL,TII->get(X86::MOV64rm),X86::R14)<br>
.addReg(X86::GS);<br>
/* 2 mov %r15, %gs:0x0(%r14) */<br>
MachineOperand baseReg = MachineOperand::CreateReg(X86::GS,false);<br>
MachineOperand scaleAmt = MachineOperand::CreateImm(0x1);<br>
MachineOperand indexReg = MachineOperand::CreateReg(X86::R14,false);<br>
MachineOperand disp = MachineOperand::CreateImm(0x0);<br>
<br>
BuildMI(MBB, MBB.end(), DL, TII->get(X86::MOV64mr))<br>
.add(baseReg)<br>
.add(scaleAmt)<br>
.add(indexReg);<br>
<br>
/* both instructions give the following error<br>
<br>
clang-6.0: /LLVM6.0.0/llvm/include/llvm/ADT/SmallVector.h:154: const<br>
T& llvm::SmallVectorTemplateCommon<T, <template-parameter-1-2><br>
>::operator[](llvm::SmallVectorTemplateCommon<T,<br>
<template-parameter-1-2> >::size_type) const [with T =<br>
llvm::MCOperand; <template-parameter-1-2> = void;<br>
llvm::SmallVectorTemplateCommon<T, <template-parameter-1-2><br>
>::const_reference = const llvm::MCOperand&;<br>
llvm::SmallVectorTemplateCommon<T, <template-parameter-1-2><br>
>::size_type = long unsigned int]: Assertion `idx < size()' failed.<br>
<br>
I saw this function in the code base but not sure what it does<br>
"addDirectMem(MachineInstructionBuilder_thing, register you want to<br>
use);"<br>
<br>
<br>
This is be the last bit of information I think I need to finish up<br>
this implementation. Thanks again for your help!<br>
<br>
Sincerely,<br>
<br>
Chris Jelesnianski<br>
<br>
On Sat, Jun 23, 2018 at 11:32 PM, Craig Topper <<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@gmail.com</a>> wrote:<br>
> The size suffix thing is a weird quirk in our assembler I should look into<br>
> fixing. Instructions in at&t syntax usually have a size suffix that is often<br>
> optional<br>
><br>
> For example:<br>
> add %ax, %bx<br>
> and<br>
> addw %ax, %bx<br>
><br>
> Are equivalent because the register name indicates the size.<br>
><br>
> but for an instruction like this<br>
> addw $1, (%ax)<br>
><br>
> There is nothing to infer the size from so an explicit suffix is required.<br>
><br>
> So for an instruction like "add %ax, %bx" from above, we try to guess the<br>
> size suffix from the register. In your case, you used a segment register<br>
> which we couldn't guess the size from. And then we printed a bad error<br>
> message.<br>
><br>
> There's no quick reference as such for the meaning of the various<br>
> X86::XXXXXX names. But the complete list of them is in<br>
> lib/Target/X86/X86GenInstrInfo.inc in your build area. The names are meant<br>
> to be fairly straight forward to understand. The first part of the name<br>
> should almost always be the instruction name from the Intel/AMD manuals. The<br>
> lower case letters at the end sort of convey operand types, but often not<br>
> the number of operands even though it looks that way. The most common<br>
> letters are 'r' for register, 'm' for memory and 'i' for immediate. Numbers<br>
> after 'i' specify the size of the immediate if its important to distinguish<br>
> from other sizes or different than the size of the instruction. The lower<br>
> case letters are most useful to distinguish different instructions from each<br>
> other. So for example, if two instructions only differ in the lower case<br>
> letters and one says "rr" and one says "rm", the first is the register form<br>
> and the second is the memory form of the same instruction.<br>
><br>
> ~Craig<br>
><br>
><br>
> On Sat, Jun 23, 2018 at 7:55 PM K Jelesnianski <<a href="mailto:kjski@vt.edu" target="_blank">kjski@vt.edu</a>> wrote:<br>
>><br>
>> Dear Craig,<br>
>><br>
>> Thank you super much for the quick reply! Yea I'm still new to working<br>
>> on the back-end and that sounds great. I already have the raw assembly<br>
>> of what I want to accomplish so this is perfect. I just tried it and<br>
>> yea, I will have to break down my assembly even further to more<br>
>> simpler operations. You're right about my assembly dealing with<br>
>> segment registers as I'm getting the following error:<br>
>> "error: unknown use of instruction mnemonic without a size suffix"<br>
>><br>
>> Just curious, what does it mean by size suffix??<br>
>><br>
>> It's super cool to see the equivalent with "-show-inst"!!! Thank you<br>
>> so much for this help!<br>
>><br>
>> Last note, I know that the definitions (e.g. def SUB32ri) of the<br>
>> various instructions can be found in the various ****.td, but is there<br>
>> documentation where the meaning or quick reference of every<br>
>> X86::XXXXXX llvm instruction macro can found, so I can quickly pick<br>
>> and choose which actual macro I need to use, to "work forwards" rather<br>
>> than working backwards by writing the assembly first and using llvm-mc<br>
>> -show-inst ??<br>
>><br>
>> Thanks super much again.<br>
>><br>
>> Sincerely,<br>
>><br>
>> Chris Jelesnianski<br>
>> Graduate Research Assistant<br>
>> Virginia Tech<br>
>><br>
>> On Sat, Jun 23, 2018 at 8:45 PM, Craig Topper <<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@gmail.com</a>><br>
>> wrote:<br>
>> > More specifically there is no instruction that can add/subtract segment<br>
>> > registers. They can only be updated my the mov segment register<br>
>> > instructions, opcodes 0x8c and 0x8e in x86 assembly.<br>
>> ><br>
>> > I suggest you write the text version of the assembly you want to<br>
>> > generate<br>
>> > and assemble it with llvm-mc. This will tell you if its even valid.<br>
>> > After<br>
>> > that you can use -show-inst to print the names of the instructions that<br>
>> > X86<br>
>> > uses that you can give to BuildMI.<br>
>> ><br>
>> > ~Craig<br>
>> ><br>
>> ><br>
>> > On Sat, Jun 23, 2018 at 5:36 PM Craig Topper <<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> The SUB32ri can't instruction can't operate on segment registers. It<br>
>> >> operates on EAX/EBX/EDX/ECX/EBP, etc. When it gets encoded only 3 or 4<br>
>> >> bits<br>
>> >> of the register value make it into the binary encoding. Objdump just<br>
>> >> extracts those 3 or 4 bits back out and prints one of the<br>
>> >> EAX/EBX/EDX/ECX/EBP registers that those bits correspond to.<br>
>> >><br>
>> >> ~Craig<br>
>> >><br>
>> >><br>
>> >> On Sat, Jun 23, 2018 at 5:28 PM K Jelesnianski via llvm-dev<br>
>> >> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> >>><br>
>> >>> Dear All,<br>
>> >>><br>
>> >>> Currently I am trying to inject custom x86-64 assembly into a<br>
>> >>> functions entry basic block. More specifically, I am trying to build<br>
>> >>> assembly in a machine function pass from scratch.<br>
>> >>><br>
>> >>> While the dumped machine function instruction info displays that %gs<br>
>> >>> will be used, when I perform objdump -d on my executable I am see that<br>
>> >>> %gs is replaced by %ebp? Why is this happening?<br>
>> >>><br>
>> >>> I know it probably has something to do with me not specifying operands<br>
>> >>> properly, but I cannot find enough documentation on this besides<br>
>> >>> looking through code comments such as X86BaseInfo.cpp. I feel there<br>
>> >>> isn't enough for me to be able to connect the dots.<br>
>> >>><br>
>> >>> Below I have sample code: %gs holds a base address to a memory<br>
>> >>> location where I am trying to store information. I am trying to update<br>
>> >>> the %gs register pointer location before saving more values, etc.<br>
>> >>><br>
>> >>> LLVM C++ codeMachine Function pass code:<br>
>> >>> MachineInstrBuilder sss = BuildMI(MBB, MBB.begin(), DL,<br>
>> >>> TII->get(X86::SUB32ri),X86::GS)<br>
>> >>> .addReg(X86::GS)<br>
>> >>> .addImm(0x8);<br>
>> >>><br>
>> >>> machine function pass dump:<br>
>> >>> %gs = SUB32ri %gs, 8, implicit-def %eflags<br>
>> >>><br>
>> >>> Objdump -d assembly from executable<br>
>> >>> 400510: 81 ed 04 00 00 00 sub $0x8,%ebp<br>
>> >>><br>
>> >>><br>
>> >>> TLDR: I am trying to create custom assembly via BuildMI() and<br>
>> >>> manipulate<br>
>> >>> segment<br>
>> >>> registers via a MachineFunctionPass.<br>
>> >>><br>
>> >>> I have looked at LLVMs safestack implementation, but they are taking a<br>
>> >>> fairly complicated hybrid approach between an IR Function pass with<br>
>> >>> Backend support. I would like to stay as a single machinefunction<br>
>> >>> pass.<br>
>> >>><br>
>> >>> Believe me I would do this at the IR level if I didnt need to<br>
>> >>> specifically use the segment registers.<br>
>> >>><br>
>> >>> Thanks for the help in advance!<br>
>> >>><br>
>> >>> Sincerely,<br>
>> >>><br>
>> >>> Christopher Jelesnianski<br>
>> >>> Graduate Research Assistant<br>
>> >>> Virginia Tech<br>
>> >>> _______________________________________________<br>
>> >>> LLVM Developers mailing list<br>
>> >>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> >>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>