capstone-users — Capstone mailing list for users

[Capstone-users] Updating X86 Instructions

[Olson, M. <mat...@in...>]

Good afternoon,

My name's Ben Olson, and I've recently switched my project from using Zydis
to do x86 disassembly, to Capstone, in order to support ARM and RISC-V. However,
in so doing, some of the x86 instructions that my users care about broke!

In particular, I'd like to add AMX-TILE, AMX-INT8, and AMX-BF16 instructions to
Capstone. I started manually editing the files in arch/X86/*.inc, but those seem
to be generated by the scripts in suite/synctools.

Should I simply run these scripts to update x86? Seems simple enough, but if so,
why hasn't someone else just quickly done that recently? I don't mind adding the
instructions manually if need be.

Thanks,
Ben Olson

[Capstone-users] r79 file dissasembly

[Joan S. <js...@ho...>]

Dear All,

I would need to dissasemble the contents of a r79 file. This file is a library of which I have 99% of the source code. I'm missing the source code of two functions but I`m certain that the r79 file contains those two functions (linker has no problem finding the functions). Since I have to maintain other functions inside the library it would be ok for me to have those two missing function in assembler format.  Is capstone or any of those 508 projects listed able to dissasemble the contents of a r79 file? Should I be developping the utility by myself? If so, where I could find r79 file format description?

Best regards,
Joan Salvat

[Capstone-users] Reducing X86_REDUCE even further

[Bahler, L. (P. LABS) <lb...@pe...>]

I want to restrict capstone disassembly of X86 even further than what is 
done for X86_REDUCE.  Let's say I have a list of opcodes in which I am 
solely interested.

We have so far been working with capstone 4.0.2.  I see the files in 
that distro that are of the form arch/x86/*_reduce.inc.  I would like to 
understand how you used tablegen to get those files and how I would 
limit them even more to reflect only the opcodes in which I am interested.

I have downloaded llvm-capstone, but I could really use some sort of 
tutorial to help me make sense of what to do.

Thanks

[Capstone-users] 5.0.0 release schedule?

[Dirk B. <dbe...@nv...>]

After several years of using v4.0.1 we find ourselves needing ARM SVE support.  Looks like that's available in 5.0.0, but I see that was released and promptly yanked.

I briefly tested 5.0.0rc2 and it appears to work for us, but before I go further I have some questions:

*) Why was 5.0.0 yanked?  What's wrong with it?

*) Do you have any idea when you are likely to make an official 5.0.0 (or 5.0.X) release?

And, related, is there an ETA for merging #1949 (autosync part 1)?  We might need that because it fixes #1983 (waiting to hear from our users how important that is).

https://github.com/capstone-engine/capstone/issues/1949
https://github.com/capstone-engine/capstone/issues/1983

Thanks.

-- 
Dirk Bergstrom
MTS Tools Guy
dbe...@nv...

[Capstone-users] What are the statuses of the current branches?

[Matt Q. <mat...@gm...>]

Hi, I'm trying to add new features to Capstone. There are multiple branches
that seemingly have divergent development going on: master, next, and v4.

What is the correct branch to build new features for? And, why are there
updates in multiple branches?

[Capstone-users] RISC-V, the 'next' branch, and next release?

[Magnus I. B. <mag...@or...>]

Hi,

I'm working with the OpenJDK project, and we currently have support for 
disassembling JITted code by using Capstone.

We added RISC-V as a supported platform some time ago, but it was just 
recently pointed out to me that Capstone does not support RISC-V.

This surprised me a lot. The front page at 
http://www.capstone-engine.org/ lists "RISCV" under 
"Multi-architectures", and searches on Google indicated that people 
where using Capstone for RISC-V.

Some further digging led me to the 'next' branch on Github, where RISC-V 
support is apparently present, and has been for a while. But it also 
became apparent that there has not been a new official release of 
Capstone for quite some time, and none with RISC-V support.

Are there any plans for a new official release, that includes RISC-V 
support? It's great that the code is present on Github, but we would 
need an official version to depend on.

/Magnus

Re: [Capstone-users] Capstone iterator functionality

[Viviana C. <viv...@gm...>]

And can I intercept this stop in such a way in my Python code? For example
with an exception

Il giorno lun 1 ago 2022 alle ore 12:19 Nguyen Anh Quynh <aq...@gm...>
ha scritto:

> yes, it stops on invalid opcode.
>
> Thanks,
> Quynh
>
>
>
> On Mon, Aug 1, 2022 at 6:08 PM Viviana Colantonio
> <viv...@gm...> wrote:
> >
> > Hi,
> >
> > I'm a Computer Engineering student and I'm working with Capstone for my
> thesis work.
> >
> > I was wondering if there is a way to know if the iterator of disasm()
> method quits the iterator when it hits an invalid op code.
> >
> > Thank you in advance.
> > _______________________________________________
> > Capstone-users mailing list
> > Cap...@li...
> > https://lists.sourceforge.net/lists/listinfo/capstone-users
>
>
> _______________________________________________
> Capstone-users mailing list
> Cap...@li...
> https://lists.sourceforge.net/lists/listinfo/capstone-users
>

Re: [Capstone-users] Capstone iterator functionality

[Nguyen A. Q. <aq...@gm...>]

yes, it stops on invalid opcode.

Thanks,
Quynh



On Mon, Aug 1, 2022 at 6:08 PM Viviana Colantonio
<viv...@gm...> wrote:
>
> Hi,
>
> I'm a Computer Engineering student and I'm working with Capstone for my thesis work.
>
> I was wondering if there is a way to know if the iterator of disasm() method quits the iterator when it hits an invalid op code.
>
> Thank you in advance.
> _______________________________________________
> Capstone-users mailing list
> Cap...@li...
> https://lists.sourceforge.net/lists/listinfo/capstone-users

[Capstone-users] Capstone iterator functionality

[Viviana C. <viv...@gm...>]

Hi,

I'm a Computer Engineering student and I'm working with Capstone for my
thesis work.

I was wondering if there is a way to know if the iterator of *disasm()*
method quits the iterator when it hits an invalid op code.

Thank you in advance.

[Capstone-users] Capstone v5

[Riccardo S. <rsc...@gm...>]

Hello all,

I am one of the maintainers of Rizin(https://rizin.re/) which uses
Capstone disassembler for many architectures. So far we are still
using Capstone v4, however we would like to move to the "next" branch
for the next release and benefit from the many improvements, new
instructions, new architectures that you added to that branch!

I was wondering whether you have any concrete plan for releasing the
next branch as v5. As distributions do not ship "next" branch as-is
but only released tags, it would be ideal to have Rizin linked against
the system capstone when the release happens. Do you have any
estimated timeline?

Thanks a lot for your great work!


Riccardo

Re: [Capstone-users] Adding disassembler for SuperH

[Thomas H. <hu...@tu...>]

On 24/06/2022 16.17, Dhruv Maroo wrote:
[...]
> We use Capstone for the disassembly wherever it is feasible. But Capstone 
> does not support SuperH. It would be nice to have SuperH disassembly support 
> within Capstone itself, since it would lead to a more uniform integration 
> between Capstone and Rizin. It'll also help anyone else looking for a SuperH 
> disassembler (since there really aren't many of them).
> 
> I can help by writing the SuperH disassembler for Capstone. I am fairly 
> familiar with the ISA and I have already partially implemented the 
> disassembler. I have also had a look at Capstone's API (for implementing x86 
> RzIL in Rizin). I can implement a complete disassembler with all the 
> instructions. I would like to hear from the maintainers and the users 
> whether I should go ahead with it (hence this mail thread).

  Hi!

My name is Thomas Huth, I just joined the mailing list recently, and I'm 
just a user of Capstone so far. I'm coming from the QEMU project which uses 
Capstone as disassembler for some of the emulated targets. From this QEMU 
point of view, a SuperH disassembler in Capstone would be very welcome - 
QEMU has a "sh4" target that could benefit from this. So far, QEMU is using 
a very old version of the GNU disassembler for this which was still licensed 
under the GPLv2:

  https://gitlab.com/qemu-project/qemu/-/blob/master/disas/sh4.c

Since QEMU can't be relicensed under GPLv3, we're stuck with this old and 
backlevel version of the code and can't use newer versions of the GNU 
disassemblers that have been relicensed with GPLv3.

So having an up-to-date and maintained SH4 disassembler in Capstone would be 
very welcome for QEMU, I think. That way we could finally get rid of the old 
GPLv2 disassembler code and just rely on Capstone.

Note that Capstone has a BSD-style license. So if you want to contribute 
your disassembler code here, it should also be licensed the same way, and 
not LGPLv3 or something similar. I hope that's not a problem for you 
(assuming you wrote all the code on your own)?

  Best regards,
   Thomas

[Capstone-users] Adding disassembler for SuperH

[Dhruv M. <dhr...@gm...>]

Hi,

I am one of the contributors of Rizin (https://github.com/rizinorg/rizin).
I have been working on lifting the SuperH ISA (
https://github.com/rizinorg/rizin/pull/2518) to the Rizin intermediate
language (RzIL). Till now, we used to use GNU's code for disassembling
SuperH opcodes (which was licensed under GPL-3). Since I was anyways
migrating the ops to RzIL, and wanted to rewrite the GPL-3 code, I rewrote
the disassembler (which is now licensed under LGPL-3). It is missing FPU
instructions, but that is mainly because we don't have IL support for them
yet, so it's not a priority.

We use Capstone for the disassembly wherever it is feasible. But Capstone
does not support SuperH. It would be nice to have SuperH disassembly
support within Capstone itself, since it would lead to a more uniform
integration between Capstone and Rizin. It'll also help anyone else looking
for a SuperH disassembler (since there really aren't many of them).

I can help by writing the SuperH disassembler for Capstone. I am fairly
familiar with the ISA and I have already partially implemented the
disassembler. I have also had a look at Capstone's API (for implementing
x86 RzIL in Rizin). I can implement a complete disassembler with all the
instructions. I would like to hear from the maintainers and the users
whether I should go ahead with it (hence this mail thread).

Regards,
Dhruv Maroo

[Capstone-users] Problem with the size of the disassembled capstone.Cs.disasm code (python)

[geokar2006 <geo...@gm...>]

I wrote this code:

from elftools.elf.elffile import ELFFile
from capstone import *
with open('file.so', "rb") as f:
    file = f.read()
    f.seek(0)
    ent = ELFFile(f).header['e_entry']
    md = Cs(CS_ARCH_ARM64, CS_MODE_LITTLE_ENDIAN)
    conv = str(file.hex())[ent*2:]
    code = bytes.fromhex(conv)
    b = list(md.disasm(code, ent))
    print(len(b))
    for i in b:
      ...

file.so this is the Android ELF arm64 (arm64-v8) library (60MB) link:
https://yadi.sk/d/f8DsmsF1CDTiZw
The size of the code ' md. disasm()` is only 17917 when if you output the
length of the part of the code that I need, it turns out to be 11227252.
Is there a way to solve the size problem?

Re: [Capstone-users] new ARM instructions

[Nguyen A. Q. <aq...@gm...>]

you should try the "next" branch on github.

$ cstool arm64be d69f0bff,4e5c0c78,4e5b0c55,f820303f,b8e0003e,88fe7e62
 0  d6 9f 0b ff  eretaa
 4  4e 5c 0c 78  fmla   v24.8h, v3.8h, v28.8h
 8  4e 5b 0c 55  fmla   v21.8h, v2.8h, v27.8h
 c  f8 20 30 3f  stset  x0, [x1]
10  b8 e0 00 3e  ldaddal        w0, w30, [x1]
14  88 fe 7e 62  casa   w30, w2, [x19]


Thanks,
Quynh

http://www.keystone-engine.org
http://www.capstone-engine.org
http://www.unicorn-engine.org


On Tue, Jun 23, 2020 at 8:06 AM Mahesh Madhav via Capstone-users
<cap...@li...> wrote:
>
> Hi!
>
>
>
> I pulled down the latest version of cstool (4.0.2) and tried to decode some new instructions, and ran into trouble:
>
>
>
> ./cstool arm64be d69f0bff,4e5c0c78,4e5b0c55,f820303f,b8e0003e,88fe7e62
>
> ERROR: invalid assembly code
>
>
>
> I tried arm64 and armv8 as the arch+mode but that didn’t help.
>
>
>
> Here is how a recent version of GNU objdump disassembles these bytes.
>
>
>
> d69f0bff    eretaa
>
> 4e5c0c78    fmla    v24.8h, v3.8h, v28.8h
>
> 4e5b0c55    fmla    v21.8h, v2.8h, v27.8h
>
> f820303f    stset   x0, [x1]
>
> b8e0003e    ldaddal w0, w30, [x1]
>
> 88fe7e62    casa    w30, w2, [x19]
>
>
>
> Am I doing something wrong in my cstool incantations? If not, what is the best way to request the newer ARM ISAs for capstone? I would very much appreciate  the additions. Thank you kindly for your time.
>
>
>
> Thanks so much,
>
> Mahesh
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Ampere Computing or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. Any review, copying, or distribution of this email (or any attachments thereto) is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
> _______________________________________________
> Capstone-users mailing list
> Cap...@li...
> https://lists.sourceforge.net/lists/listinfo/capstone-users

[Capstone-users] new ARM instructions

[Mahesh M. <ma...@am...>]

Hi!

I pulled down the latest version of cstool (4.0.2) and tried to decode some new instructions, and ran into trouble:

./cstool arm64be d69f0bff,4e5c0c78,4e5b0c55,f820303f,b8e0003e,88fe7e62
ERROR: invalid assembly code

I tried arm64 and armv8 as the arch+mode but that didn’t help.

Here is how a recent version of GNU objdump disassembles these bytes.

d69f0bff    eretaa
4e5c0c78    fmla    v24.8h, v3.8h, v28.8h
4e5b0c55    fmla    v21.8h, v2.8h, v27.8h
f820303f    stset   x0, [x1]
b8e0003e    ldaddal w0, w30, [x1]
88fe7e62    casa    w30, w2, [x19]

Am I doing something wrong in my cstool incantations? If not, what is the best way to request the newer ARM ISAs for capstone? I would very much appreciate  the additions. Thank you kindly for your time.

Thanks so much,
Mahesh


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Ampere Computing or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. Any review, copying, or distribution of this email (or any attachments thereto) is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

[Capstone-users] Capstone 4.0.2 is out!

[Nguyen A. Q. <aq...@gm...>]

Greetings,

We are happy to announce version 4.0.2 of Capstone disassembler framework!

This release fixes some bugs of v4.0.1, and introduces some
improvements for several bindings. We strongly encourage all users of
v4.0.1 to upgrade.

In no particular order, we would like to thank Senrio.io and
Catenacyber.fr for sponsoring this release!

We also wish to express our sincere gratitude to all contributors &
donators, who generously supported us to maintain Capstone project!

More details are available at http://www.capstone-engine.org/Version-4.0.2

(For those who do not know, Capstone is an open source multi-arch,
multi-platform disassembly engine, with homepage at
http://capstone-engine.org).

Thanks,
Quynh

http://www.keystone-engine.org
http://www.capstone-engine.org
http://www.unicorn-engine.org

Re: [Capstone-users] [EXTERNAL] Re: ARMv8-M support

[Lizarraga, E. <e-l...@ti...>]

Hi Quynh,

Thanks for following up. I haven't tried your suggestion but I looked at it and I can see the missing instructions are already included.

When is that version going to be officially released?

Thanks,

Enrique

-----Original Message-----
From: Nguyen Anh Quynh [mailto:aq...@gm...] 
Sent: Sunday, December 15, 2019 1:41 AM
To: Capstone disassembly framework (www.capstone-engine.org)
Cc: Lizarraga, Enrique
Subject: [EXTERNAL] Re: [Capstone-users] ARMv8-M support

can you try with the "next" branch on Github, which supports latest
instructions?

Thanks,
Quynh

http://www.keystone-engine.org
http://www.capstone-engine.org
http://www.unicorn-engine.org



On Fri, Dec 13, 2019 at 7:19 AM Lizarraga, Enrique via Capstone-users
<cap...@li...> wrote:
>
> Good afternoon,
>
>
>
> Is ARMv8-M officially supported in the latest Capstone Disassembler version (4.0.1)?  The website mentions Armv8, but I couldn’t find any references to some of the new instructions added for ARMv8-M (for example BXNS or BLXNS).
>
>
>
> Thank you,
>
>
>
> Enrique Lizárraga
>
>
>
> _______________________________________________
> Capstone-users mailing list
> Cap...@li...
> https://lists.sourceforge.net/lists/listinfo/capstone-users

Re: [Capstone-users] ARMv8-M support

[Nguyen A. Q. <aq...@gm...>]

can you try with the "next" branch on Github, which supports latest
instructions?

Thanks,
Quynh

http://www.keystone-engine.org
http://www.capstone-engine.org
http://www.unicorn-engine.org



On Fri, Dec 13, 2019 at 7:19 AM Lizarraga, Enrique via Capstone-users
<cap...@li...> wrote:
>
> Good afternoon,
>
>
>
> Is ARMv8-M officially supported in the latest Capstone Disassembler version (4.0.1)?  The website mentions Armv8, but I couldn’t find any references to some of the new instructions added for ARMv8-M (for example BXNS or BLXNS).
>
>
>
> Thank you,
>
>
>
> Enrique Lizárraga
>
>
>
> _______________________________________________
> Capstone-users mailing list
> Cap...@li...
> https://lists.sourceforge.net/lists/listinfo/capstone-users

[Capstone-users] ARMv8-M support

[Lizarraga, E. <e-l...@ti...>]

Good afternoon,

Is ARMv8-M officially supported in the latest Capstone Disassembler version (4.0.1)?  The website mentions Armv8, but I couldn't find any references to some of the new instructions added for ARMv8-M (for example BXNS or BLXNS).

Thank you,

Enrique Lizárraga

[Capstone-users] Disassembly problem

[Roy A. <roy...@ka...>]

Hi all,

I am using capstone x86-64 and I think there is a bug in the iterator function:
I am using cs_insn->detail->x86.encoding, and it looks like
the call  "r = handle->disasm(ud, *code, *size, &mci, &insn_size, *address, handle->getinsn_info);"
is filling this structure correctly, but sometimes the call to
"handle->printer(&mci, &ss, handle->printer_info);"

ruins the values in it.
Does this sound familiar?

Thanks
Roy

Re: [Capstone-users] Adding regs_access support for PPC and MIPS

[Nguyen A. Q. <aq...@gm...>]

On Fri, Aug 9, 2019, 04:16 Derrick McKee <der...@gm...> wrote:

> It was taking too long to write all this, so I went a different route. The
> good news is that I have generated the PPC and Mips instruction operand
> mapping.  However, I am kind of confused as to where I should be calling
> the set_mem_access function in the respective InstWriter.c files (and
> associated GenInstWrite.inc files).  Any intuition as to where they should
> be placed would be appreciated.  Thanks!
>

That function is to set memory access property for related operand. You can
take some examples having memory operand, and see how your new code works.

If you are still unsure, no worry, i can help with that after i see your
code.

Cheers.








> On Wed, Jul 31, 2019 at 8:29 AM Derrick McKee <der...@gm...>
> wrote:
>
>> The idea is to make the generation of the needed inc file less of a black
>> box, and ensure that it is properly ordered.
>>
>> On Wed, Jul 31, 2019, 06:42 Nguyen Anh Quynh <aq...@gm...> wrote:
>>
>>>
>>>
>>> On Tue, Jul 30, 2019, 23:07 Derrick McKee <der...@gm...>
>>> wrote:
>>>
>>>> So, looking closer at the existing MappingInsnOp.inc files, it looks
>>>> like my proposed YAML format is not suitable. So instead I propose the
>>>> following:
>>>>
>>>> output: "MipMappingInsnOp.inc"
>>>> Insns:
>>>> - enum: MIPS_INS_ABSQ_S
>>>>   subtypes:
>>>>     - examples: {
>>>>       Mips_ABSQ_S_PH: "ABSQ_S.PH  rd, rt",
>>>>       Mips_ABSQ_S_QB: "ABSQ_S.QB rd, rt",
>>>>       Mips_ABSQ_S_W: "ABSQ_S.W  rd, rt"
>>>>     }
>>>>       operands:
>>>>         - read: No
>>>>           write: Yes
>>>>         - read: Yes
>>>>           write: No
>>>>
>>>
>>> Yes sounds good.
>>>
>>> But how does this make it better than current .inc format? A bit more
>>> readability, but not too much to me.
>>>
>>>
>>>
>>>>
>>>> On Tue, Jul 30, 2019 at 8:45 AM Derrick McKee <der...@gm...>
>>>> wrote:
>>>>
>>>>> I think I am mostly done with the C implementation, and have updated
>>>>> the bindings. I just need to generate the {Mips,PPC}MappingInsnOp.inc
>>>>> files.  The existing files for ARM and x86 seem to contain the read/write
>>>>> information for every instruction, sorted by enum name.  They also say that
>>>>> they were autogenerated, but I guess that isn't quite correct.  I am
>>>>> thinking that I can write a Python script that reads in a YAML file, and
>>>>> outputs the properly sorted inc file containing all the information
>>>>> (including comments) currently in existing InsnOp.inc files.  The YAML file
>>>>> will have a structure like the following:
>>>>>
>>>>> output: "MipsMappingInsnOp.inc"
>>>>> Insns:
>>>>>     - enum: MIPS_INS_ADD
>>>>>       example: "add $d, $t, $s"
>>>>>       operands:
>>>>>           - read: No
>>>>>             write: Yes
>>>>>           - read: Yes
>>>>>             write: No
>>>>>           - read: Yes
>>>>>             write: No
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> On Tue, Jul 30, 2019 at 1:24 AM Nguyen Anh Quynh <aq...@gm...>
>>>>> wrote:
>>>>>
>>>>>> Those .inc files involved a lot of manual work, that is why it takes
>>>>>> time.
>>>>>>
>>>>>> What is your progress?
>>>>>>
>>>>>> Cheers.
>>>>>>
>>>>>> On Mon, Jul 29, 2019, 23:47 Derrick McKee <der...@gm...>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am beginning to add support for regs_access for MIPS and PPC.
>>>>>>> Currently, I am following what has been done for ARM and x86, which as far
>>>>>>> as I can tell for PPC involves adding a new access member to the
>>>>>>> cs_ppc_op struct, writing a new PPC_regs_access function, and
>>>>>>> setting the regs_access function pointer in cs_struct in
>>>>>>> PPC_global_init.  My question is how is the access member set?  For
>>>>>>> both ARM and x86, there is a MappingInsnOp.inc file that appears to be
>>>>>>> autogenerated, which contains the access information.  How was this file
>>>>>>> generated?
>>>>>>>
>>>>>>> --
>>>>>>> Derrick McKee
>>>>>>> Phone: (703) 957-9362
>>>>>>> Email: der...@gm...
>>>>>>> _______________________________________________
>>>>>>> Capstone-users mailing list
>>>>>>> Cap...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Capstone-users mailing list
>>>>>> Cap...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Derrick McKee
>>>>> Phone: (703) 957-9362
>>>>> Email: der...@gm...
>>>>>
>>>>
>>>>
>>>> --
>>>> Derrick McKee
>>>> Phone: (703) 957-9362
>>>> Email: der...@gm...
>>>> _______________________________________________
>>>> Capstone-users mailing list
>>>> Cap...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>>>
>>> _______________________________________________
>>> Capstone-users mailing list
>>> Cap...@li...
>>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>>
>>
>
> --
> Derrick McKee
> Phone: (703) 957-9362
> Email: der...@gm...
> _______________________________________________
> Capstone-users mailing list
> Cap...@li...
> https://lists.sourceforge.net/lists/listinfo/capstone-users
>

Re: [Capstone-users] Adding regs_access support for PPC and MIPS

[Derrick M. <der...@gm...>]

It was taking too long to write all this, so I went a different route. The
good news is that I have generated the PPC and Mips instruction operand
mapping.  However, I am kind of confused as to where I should be calling
the set_mem_access function in the respective InstWriter.c files (and
associated GenInstWrite.inc files).  Any intuition as to where they should
be placed would be appreciated.  Thanks!

On Wed, Jul 31, 2019 at 8:29 AM Derrick McKee <der...@gm...>
wrote:

> The idea is to make the generation of the needed inc file less of a black
> box, and ensure that it is properly ordered.
>
> On Wed, Jul 31, 2019, 06:42 Nguyen Anh Quynh <aq...@gm...> wrote:
>
>>
>>
>> On Tue, Jul 30, 2019, 23:07 Derrick McKee <der...@gm...>
>> wrote:
>>
>>> So, looking closer at the existing MappingInsnOp.inc files, it looks
>>> like my proposed YAML format is not suitable. So instead I propose the
>>> following:
>>>
>>> output: "MipMappingInsnOp.inc"
>>> Insns:
>>> - enum: MIPS_INS_ABSQ_S
>>>   subtypes:
>>>     - examples: {
>>>       Mips_ABSQ_S_PH: "ABSQ_S.PH  rd, rt",
>>>       Mips_ABSQ_S_QB: "ABSQ_S.QB rd, rt",
>>>       Mips_ABSQ_S_W: "ABSQ_S.W  rd, rt"
>>>     }
>>>       operands:
>>>         - read: No
>>>           write: Yes
>>>         - read: Yes
>>>           write: No
>>>
>>
>> Yes sounds good.
>>
>> But how does this make it better than current .inc format? A bit more
>> readability, but not too much to me.
>>
>>
>>
>>>
>>> On Tue, Jul 30, 2019 at 8:45 AM Derrick McKee <der...@gm...>
>>> wrote:
>>>
>>>> I think I am mostly done with the C implementation, and have updated
>>>> the bindings. I just need to generate the {Mips,PPC}MappingInsnOp.inc
>>>> files.  The existing files for ARM and x86 seem to contain the read/write
>>>> information for every instruction, sorted by enum name.  They also say that
>>>> they were autogenerated, but I guess that isn't quite correct.  I am
>>>> thinking that I can write a Python script that reads in a YAML file, and
>>>> outputs the properly sorted inc file containing all the information
>>>> (including comments) currently in existing InsnOp.inc files.  The YAML file
>>>> will have a structure like the following:
>>>>
>>>> output: "MipsMappingInsnOp.inc"
>>>> Insns:
>>>>     - enum: MIPS_INS_ADD
>>>>       example: "add $d, $t, $s"
>>>>       operands:
>>>>           - read: No
>>>>             write: Yes
>>>>           - read: Yes
>>>>             write: No
>>>>           - read: Yes
>>>>             write: No
>>>>
>>>> Thoughts?
>>>>
>>>> On Tue, Jul 30, 2019 at 1:24 AM Nguyen Anh Quynh <aq...@gm...>
>>>> wrote:
>>>>
>>>>> Those .inc files involved a lot of manual work, that is why it takes
>>>>> time.
>>>>>
>>>>> What is your progress?
>>>>>
>>>>> Cheers.
>>>>>
>>>>> On Mon, Jul 29, 2019, 23:47 Derrick McKee <der...@gm...>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am beginning to add support for regs_access for MIPS and PPC.
>>>>>> Currently, I am following what has been done for ARM and x86, which as far
>>>>>> as I can tell for PPC involves adding a new access member to the
>>>>>> cs_ppc_op struct, writing a new PPC_regs_access function, and
>>>>>> setting the regs_access function pointer in cs_struct in
>>>>>> PPC_global_init.  My question is how is the access member set?  For
>>>>>> both ARM and x86, there is a MappingInsnOp.inc file that appears to be
>>>>>> autogenerated, which contains the access information.  How was this file
>>>>>> generated?
>>>>>>
>>>>>> --
>>>>>> Derrick McKee
>>>>>> Phone: (703) 957-9362
>>>>>> Email: der...@gm...
>>>>>> _______________________________________________
>>>>>> Capstone-users mailing list
>>>>>> Cap...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>>>>>
>>>>> _______________________________________________
>>>>> Capstone-users mailing list
>>>>> Cap...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>>>>
>>>>
>>>>
>>>> --
>>>> Derrick McKee
>>>> Phone: (703) 957-9362
>>>> Email: der...@gm...
>>>>
>>>
>>>
>>> --
>>> Derrick McKee
>>> Phone: (703) 957-9362
>>> Email: der...@gm...
>>> _______________________________________________
>>> Capstone-users mailing list
>>> Cap...@li...
>>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>>
>> _______________________________________________
>> Capstone-users mailing list
>> Cap...@li...
>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>
>

-- 
Derrick McKee
Phone: (703) 957-9362
Email: der...@gm...

Re: [Capstone-users] Adding regs_access support for PPC and MIPS

[Derrick M. <der...@gm...>]

The idea is to make the generation of the needed inc file less of a black
box, and ensure that it is properly ordered.

On Wed, Jul 31, 2019, 06:42 Nguyen Anh Quynh <aq...@gm...> wrote:

>
>
> On Tue, Jul 30, 2019, 23:07 Derrick McKee <der...@gm...> wrote:
>
>> So, looking closer at the existing MappingInsnOp.inc files, it looks like
>> my proposed YAML format is not suitable. So instead I propose the following:
>>
>> output: "MipMappingInsnOp.inc"
>> Insns:
>> - enum: MIPS_INS_ABSQ_S
>>   subtypes:
>>     - examples: {
>>       Mips_ABSQ_S_PH: "ABSQ_S.PH  rd, rt",
>>       Mips_ABSQ_S_QB: "ABSQ_S.QB rd, rt",
>>       Mips_ABSQ_S_W: "ABSQ_S.W  rd, rt"
>>     }
>>       operands:
>>         - read: No
>>           write: Yes
>>         - read: Yes
>>           write: No
>>
>
> Yes sounds good.
>
> But how does this make it better than current .inc format? A bit more
> readability, but not too much to me.
>
>
>
>>
>> On Tue, Jul 30, 2019 at 8:45 AM Derrick McKee <der...@gm...>
>> wrote:
>>
>>> I think I am mostly done with the C implementation, and have updated the
>>> bindings. I just need to generate the {Mips,PPC}MappingInsnOp.inc files.
>>> The existing files for ARM and x86 seem to contain the read/write
>>> information for every instruction, sorted by enum name.  They also say that
>>> they were autogenerated, but I guess that isn't quite correct.  I am
>>> thinking that I can write a Python script that reads in a YAML file, and
>>> outputs the properly sorted inc file containing all the information
>>> (including comments) currently in existing InsnOp.inc files.  The YAML file
>>> will have a structure like the following:
>>>
>>> output: "MipsMappingInsnOp.inc"
>>> Insns:
>>>     - enum: MIPS_INS_ADD
>>>       example: "add $d, $t, $s"
>>>       operands:
>>>           - read: No
>>>             write: Yes
>>>           - read: Yes
>>>             write: No
>>>           - read: Yes
>>>             write: No
>>>
>>> Thoughts?
>>>
>>> On Tue, Jul 30, 2019 at 1:24 AM Nguyen Anh Quynh <aq...@gm...>
>>> wrote:
>>>
>>>> Those .inc files involved a lot of manual work, that is why it takes
>>>> time.
>>>>
>>>> What is your progress?
>>>>
>>>> Cheers.
>>>>
>>>> On Mon, Jul 29, 2019, 23:47 Derrick McKee <der...@gm...>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am beginning to add support for regs_access for MIPS and PPC.
>>>>> Currently, I am following what has been done for ARM and x86, which as far
>>>>> as I can tell for PPC involves adding a new access member to the
>>>>> cs_ppc_op struct, writing a new PPC_regs_access function, and setting
>>>>> the regs_access function pointer in cs_struct in PPC_global_init.  My
>>>>> question is how is the access member set?  For both ARM and x86, there is a
>>>>> MappingInsnOp.inc file that appears to be autogenerated, which contains the
>>>>> access information.  How was this file generated?
>>>>>
>>>>> --
>>>>> Derrick McKee
>>>>> Phone: (703) 957-9362
>>>>> Email: der...@gm...
>>>>> _______________________________________________
>>>>> Capstone-users mailing list
>>>>> Cap...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>>>>
>>>> _______________________________________________
>>>> Capstone-users mailing list
>>>> Cap...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>>>
>>>
>>>
>>> --
>>> Derrick McKee
>>> Phone: (703) 957-9362
>>> Email: der...@gm...
>>>
>>
>>
>> --
>> Derrick McKee
>> Phone: (703) 957-9362
>> Email: der...@gm...
>> _______________________________________________
>> Capstone-users mailing list
>> Cap...@li...
>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>
> _______________________________________________
> Capstone-users mailing list
> Cap...@li...
> https://lists.sourceforge.net/lists/listinfo/capstone-users
>

Re: [Capstone-users] Adding regs_access support for PPC and MIPS

[Nguyen A. Q. <aq...@gm...>]

On Tue, Jul 30, 2019, 23:07 Derrick McKee <der...@gm...> wrote:

> So, looking closer at the existing MappingInsnOp.inc files, it looks like
> my proposed YAML format is not suitable. So instead I propose the following:
>
> output: "MipMappingInsnOp.inc"
> Insns:
> - enum: MIPS_INS_ABSQ_S
>   subtypes:
>     - examples: {
>       Mips_ABSQ_S_PH: "ABSQ_S.PH  rd, rt",
>       Mips_ABSQ_S_QB: "ABSQ_S.QB rd, rt",
>       Mips_ABSQ_S_W: "ABSQ_S.W  rd, rt"
>     }
>       operands:
>         - read: No
>           write: Yes
>         - read: Yes
>           write: No
>

Yes sounds good.

But how does this make it better than current .inc format? A bit more
readability, but not too much to me.



>
> On Tue, Jul 30, 2019 at 8:45 AM Derrick McKee <der...@gm...>
> wrote:
>
>> I think I am mostly done with the C implementation, and have updated the
>> bindings. I just need to generate the {Mips,PPC}MappingInsnOp.inc files.
>> The existing files for ARM and x86 seem to contain the read/write
>> information for every instruction, sorted by enum name.  They also say that
>> they were autogenerated, but I guess that isn't quite correct.  I am
>> thinking that I can write a Python script that reads in a YAML file, and
>> outputs the properly sorted inc file containing all the information
>> (including comments) currently in existing InsnOp.inc files.  The YAML file
>> will have a structure like the following:
>>
>> output: "MipsMappingInsnOp.inc"
>> Insns:
>>     - enum: MIPS_INS_ADD
>>       example: "add $d, $t, $s"
>>       operands:
>>           - read: No
>>             write: Yes
>>           - read: Yes
>>             write: No
>>           - read: Yes
>>             write: No
>>
>> Thoughts?
>>
>> On Tue, Jul 30, 2019 at 1:24 AM Nguyen Anh Quynh <aq...@gm...>
>> wrote:
>>
>>> Those .inc files involved a lot of manual work, that is why it takes
>>> time.
>>>
>>> What is your progress?
>>>
>>> Cheers.
>>>
>>> On Mon, Jul 29, 2019, 23:47 Derrick McKee <der...@gm...>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I am beginning to add support for regs_access for MIPS and PPC.
>>>> Currently, I am following what has been done for ARM and x86, which as far
>>>> as I can tell for PPC involves adding a new access member to the
>>>> cs_ppc_op struct, writing a new PPC_regs_access function, and setting
>>>> the regs_access function pointer in cs_struct in PPC_global_init.  My
>>>> question is how is the access member set?  For both ARM and x86, there is a
>>>> MappingInsnOp.inc file that appears to be autogenerated, which contains the
>>>> access information.  How was this file generated?
>>>>
>>>> --
>>>> Derrick McKee
>>>> Phone: (703) 957-9362
>>>> Email: der...@gm...
>>>> _______________________________________________
>>>> Capstone-users mailing list
>>>> Cap...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>>>
>>> _______________________________________________
>>> Capstone-users mailing list
>>> Cap...@li...
>>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>>
>>
>>
>> --
>> Derrick McKee
>> Phone: (703) 957-9362
>> Email: der...@gm...
>>
>
>
> --
> Derrick McKee
> Phone: (703) 957-9362
> Email: der...@gm...
> _______________________________________________
> Capstone-users mailing list
> Cap...@li...
> https://lists.sourceforge.net/lists/listinfo/capstone-users
>

Re: [Capstone-users] Adding regs_access support for PPC and MIPS

[Derrick M. <der...@gm...>]

So, looking closer at the existing MappingInsnOp.inc files, it looks like
my proposed YAML format is not suitable. So instead I propose the following:

output: "MipMappingInsnOp.inc"
Insns:
- enum: MIPS_INS_ABSQ_S
  subtypes:
    - examples: {
      Mips_ABSQ_S_PH: "ABSQ_S.PH  rd, rt",
      Mips_ABSQ_S_QB: "ABSQ_S.QB rd, rt",
      Mips_ABSQ_S_W: "ABSQ_S.W  rd, rt"
    }
      operands:
        - read: No
          write: Yes
        - read: Yes
          write: No


On Tue, Jul 30, 2019 at 8:45 AM Derrick McKee <der...@gm...>
wrote:

> I think I am mostly done with the C implementation, and have updated the
> bindings. I just need to generate the {Mips,PPC}MappingInsnOp.inc files.
> The existing files for ARM and x86 seem to contain the read/write
> information for every instruction, sorted by enum name.  They also say that
> they were autogenerated, but I guess that isn't quite correct.  I am
> thinking that I can write a Python script that reads in a YAML file, and
> outputs the properly sorted inc file containing all the information
> (including comments) currently in existing InsnOp.inc files.  The YAML file
> will have a structure like the following:
>
> output: "MipsMappingInsnOp.inc"
> Insns:
>     - enum: MIPS_INS_ADD
>       example: "add $d, $t, $s"
>       operands:
>           - read: No
>             write: Yes
>           - read: Yes
>             write: No
>           - read: Yes
>             write: No
>
> Thoughts?
>
> On Tue, Jul 30, 2019 at 1:24 AM Nguyen Anh Quynh <aq...@gm...> wrote:
>
>> Those .inc files involved a lot of manual work, that is why it takes time.
>>
>> What is your progress?
>>
>> Cheers.
>>
>> On Mon, Jul 29, 2019, 23:47 Derrick McKee <der...@gm...>
>> wrote:
>>
>>> Hi,
>>>
>>> I am beginning to add support for regs_access for MIPS and PPC.
>>> Currently, I am following what has been done for ARM and x86, which as far
>>> as I can tell for PPC involves adding a new access member to the
>>> cs_ppc_op struct, writing a new PPC_regs_access function, and setting
>>> the regs_access function pointer in cs_struct in PPC_global_init.  My
>>> question is how is the access member set?  For both ARM and x86, there is a
>>> MappingInsnOp.inc file that appears to be autogenerated, which contains the
>>> access information.  How was this file generated?
>>>
>>> --
>>> Derrick McKee
>>> Phone: (703) 957-9362
>>> Email: der...@gm...
>>> _______________________________________________
>>> Capstone-users mailing list
>>> Cap...@li...
>>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>>
>> _______________________________________________
>> Capstone-users mailing list
>> Cap...@li...
>> https://lists.sourceforge.net/lists/listinfo/capstone-users
>>
>
>
> --
> Derrick McKee
> Phone: (703) 957-9362
> Email: der...@gm...
>


-- 
Derrick McKee
Phone: (703) 957-9362
Email: der...@gm...