-
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Various enhancements for e asm.cpu #194
Comments
Quick opinions I have on this:
The hardware ecology is enormous and I think it is useful as a general "cpu family"/"Instruction set" label. From my PoV, what I would like is to have a way of importing existing hardware data description documents (e.g. https://github.com/posborne/cmsis-svd ) so that reversing stuff on particular chipsets is easier - if you see a ldr r0,[0x40013804] on an stm32l4x6 it can be flagged as a read on the CR2 register for the USART1 peripheral and not require continuously referring to the datasheet to look up memory mapped peripheral accesses to understand what they're doing. Initially it wouldn't have to be able to do anything clever like emulation, just automatically recognising an address is listed in a system view description document selected by the user. The document format is specified here for general purpose further information. I understand they're not always consistent and often unofficial, but even a minimal python wrapper -> r2 specification converter would be surprisingly helpful (and it would leverage all the work that has been done elsewhere creating system descriptor files in the first place). At the same time, an additional benefit would be that by the bulk of describing peripherals outside of r2, it becomes the responsibility of people maintaining those chipset documents, etc rather than a huge maintenance burden in the core project handling less "obvious" io configurations (like 32bit registers which are remapped repeatedly in slices across a 1kb to give safe bit slice accessing). This is important because there are thousands of differently configured chips around, so it's not feasible to implement new functionality for each, even for trivial differences. At the same time I understand that support for AVR has run in to some similar, related issues. I don't know so much about them, but I think it's important to create an integrated system with good separation of responsibilities between components so it's ergonomic for users to configure for whatever they're hacking on (like me, I really want to be able to do this with r2, and I can already do similar by register addresses as flags, but I suspect it could be better. :-) ). |
Similar parseable documents also exist for AVR devices, in a somewhat different format (ATDF) |
Check my previous unfinished PR for this. Will update it a bit later
…On Sep 11, 2017 12:18 AM, "Maijin" ***@***.***> wrote:
During r2con several people expressed concern about the current way e
asm.cpu (models of CPU) works, especially the fact that it requires to
touch code for adding new CPU IO description (https://github.com/radare/
radare2/blob/c0c0cba3398466661afed716f709f1fc404a752e/libr/syscall/
ioports.c#L11) where it could go in a CPU files. (Parsing from
(cmsis/SWD) via a script and put info in a sdb.txt for example)
Also it has been said that e asm.cpu in arm contains currently cortex-m
and v8 where it should contains chips models like in AVR and therefore
there should be a way to describe the ISA and the chipset. e asm.cpu is
also said to be underused and could contain much more interesting
information on the models to be discussed.
I have opened an HackMD for discussion https://hackmd.io/
IwYwRgbBwJwCYFoBmBDJSEBYDsAmbCYK4hKAzAKxJiWa65JA
ping @killabytenow <https://github.com/killabytenow> @queenp
<https://github.com/queenp> @dukebarman <https://github.com/dukebarman>
@Darkkey <https://github.com/darkkey> @brainstorm
<https://github.com/brainstorm> @XVilka <https://github.com/xvilka>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/radare/radare2/issues/8467>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMZ_VWQf7AGmXHDlCiXU1MqApr37UQjks5shAvKgaJpZM4PSXfs>
.
|
Basically I'm suggesting to use syscalls-like approach for both IO ports and MMIO mapped registers - like here radareorg/radare2#8473 |
Seems to define the name of the CPU, RAM_SIZE, ROM_SIZE, INTERRUPT_VECTOR_SIZE, IO_REGISTERS/EXTENDED_IO_REGISTERS. We should do this for this part of the code https://github.com/radare/radare2/blob/master/libr/anal/p/anal_avr.c#L15-L247 |
ive merged the sysreg pr and rewrote it. so now the things are like this:
|
I will offer 0.1 BTC to the one who will fix this issue. Initially, I wanted to use BountySource, but its support for bitcoins is a plain nightmare. So I will offer it directly. |
I am interested in doing this, and will start working on it post RSoC :) |
@deepakchethan if you are on telegram we can sync to discuss this task together with @XVilka |
@Maijin, Yes I am on telegram. I will ping you on it :) |
@deepakchethan so, are you up for this task? |
Yes, i'm going through a lot of changes in my IRL and will get back to radare2 contributions by the end of this week. I am sorry about the delay. |
@deepakchethan any updates regarding this one? |
I am working on r_syscall_sysreg. Where do you want to store the info on io, reg, mem? |
We could have a collection of sdb file for every specific archi, and the user could load the specific file if he want.
|
Good enthusiast but wait 😄 - there is a lot to do here, don't rush things out, don't forget that this issue is meant as a full project for GSOC, you will have to come up with a calendar/planning you'll discuss with the mentor of that project! But yes one of the idea is to have files with the configuration per CPUs instead of hardcoded configuration. Understanding and making r_syscall_sysreg working is a first step - check how that's working now and you can improve it on the model of the e asm.describe and a simple sdb structure. |
This issue has been moved from radareorg/radare2 to radareorg/ideas as we are trying to clean our backlog and this issue has probably been created a long while ago. This is an effort to help contributors understand what are the actionable items they can work on, prioritize issues better and help users find active/duplicated issues more easily. If this is not an enhancement/improvement/general idea but a bug, feel free to ask for re-transfer to main repo. Thanks for your understanding and contribution with this issue. |
Old message
Store system registry information
Tasks:
Store CPU information
Tasks:
Examples of files which needs to be cleanup and improved
Examples - using hardcoded values
Examples Using SVD (Subtasked into radareorg/radare2#15484)
Other projects
The text was updated successfully, but these errors were encountered: