Port to ARM

[eteran]

EDB should be able to support ARM. I suspect that a lot of the code will "just work", but there is much to be done.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[10110111]

Do you have any plans on how to start doing this? What actual hardware do you suppose to test on? I only currently have Raspberry Pi 1 Model B, but not sure how slow the compilation is going to be.

[eteran]

I have a Pi 3 arriving tomorrow :-)

[eteran]

@10110111 If I get the ball rolling on this, any chance you'd have the time to make an ARM version of the register view plugin? Do youy know if ARM has a decent amount of specially registers like x86 does? A quick googling doesn't reveal much.

[10110111]

I will try as time permits, yes. Although I don't know much of the ARM architecture, it seems there's nothing that much special about its registers. I seem to remember GDB printing most of what we want by its info all-registers command.

[10110111]

From what I've researched, in a userspace process there are the following registers:

• 16 GPRs, 3 of which are special: SP, LR and PC
• CPSR (similar to EFLAGS on x86)
• 32 single-precision or 16 double-precision FPU registers, where the former alias the latter (similar to MMx registers on x86)
• FPSCR (similar to MXCSR on x86)

So there is something to make nice — flags, controls (like FPU exception masks) and vector registers.

There are also some system registers, invisible to userspace, but I'm not sure whether there are any debug registers like DRx on x86 worth putting into the register view.

[eteran]

Awesome thanks for your research on this. My Pi arrived today, waiting on the case to arrive tomorrow. I think I'll be able to start the porting work next week.

I'm pretty excited to make headway on this feature since it is literally a tool I wish I had for work last week 😉

[10110111]

For quick reference, here are some docs (paths to the actual docs are given just in case the links work strangely):

• CPSR: Home > Programmer’s Model > The program status registers
• FPSCR: Home > VFP Programmer’s Model > VFP11 system registers > Floating-Point Status and Control Register, FPSCR
• GPRs: Home > Programmer’s Model > Registers > The register set
• VFP data registers: Home > VFP Register File > Decoding the register file

Apparently R13 is used as SP as a convention, not enforced architecturally.

[10110111]

BTW, do you actually build EDB on your Raspberry? Or do you cross-compile it?

[eteran]

I've been running the builds on the pi itself. So far it of course doesn't succeed though. Timing not too bad, but it is much slower than my laptop of course

[10110111]

The register set of ARM appears to be quite rich, even not counting AArch64 (which BTW your version of RPi does support, unlike mine). There appears to be a host of differences between VFPv2 and VFPv3-D32, as well as NEON:

• VFPv2: S0-S31 (binary32 floats) aliased to D0-D15 (binary64 floats)
• VFPv3-D32: S0-S31 aliased to D0-D15 + additional D16-D31 not aliased to anything
• (VFP+)NEON: S0-S31 (binary32 floats) aliased to D0-D31 aliased to Q0-Q15, where Dn and Qn can be arrays of different integer and floating-point types.

You can try my fork of gdb-dashboard, which attempts to make a mock-up of the register set as I suppose it should look in EDB. To try it out, copy or link dashboard-setup.py from init.my into ~/.gdbinit.d/ (be sure to use my-own-format branch, not master), and then in GDB issue

source /path/to/gdb-dashboard/.gdbinit
dashboard -layout archregs
file /path/to/some/test-program
b *0
r
d 1
dashboard

Then you can try stepping, running etc., seeing the changed registers highlight :)

This code doesn't yet present SIMD registers in any other form than hex dwords, but it's already something.

Myself, I tested that showing Qn registers even works, via gdbserver on my Lenovo A328 phone.