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

Port to ARM #560

Open
eteran opened this Issue Jun 25, 2017 · 10 comments

Comments

Projects
None yet
2 participants
@eteran
Owner

eteran commented Jun 25, 2017

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.

@eteran eteran added the enhancement label Jun 25, 2017

@10110111

This comment has been minimized.

Show comment
Hide comment
@10110111

10110111 Jun 28, 2017

Contributor

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.

Contributor

10110111 commented Jun 28, 2017

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

This comment has been minimized.

Show comment
Hide comment
@eteran

eteran Jun 28, 2017

Owner

I have a Pi 3 arriving tomorrow :-)

Owner

eteran commented Jun 28, 2017

I have a Pi 3 arriving tomorrow :-)

@eteran

This comment has been minimized.

Show comment
Hide comment
@eteran

eteran Jun 28, 2017

Owner

@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.

Owner

eteran commented Jun 28, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@10110111

10110111 Jun 29, 2017

Contributor

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.

Contributor

10110111 commented Jun 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@10110111

10110111 Jun 29, 2017

Contributor

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.

Contributor

10110111 commented Jun 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@eteran

eteran Jun 29, 2017

Owner

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 😉

Owner

eteran commented Jun 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@10110111

10110111 Jun 30, 2017

Contributor

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.

Contributor

10110111 commented Jun 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@10110111

10110111 Jul 6, 2017

Contributor

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

Contributor

10110111 commented Jul 6, 2017

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

@eteran

This comment has been minimized.

Show comment
Hide comment
@eteran

eteran Jul 6, 2017

Owner

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

Owner

eteran commented Jul 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@10110111

10110111 Aug 5, 2017

Contributor

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.

Contributor

10110111 commented Aug 5, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment