Get Error 'Error: should be able to read register state'

[jaredhagel]

First off, love the project! Thanks for open sourcing it. I haven't found this functionality elsewhere for Linux. I found out about if from this post - https://stackoverflow.com/a/77533835/9463631. I'm glad it's written in Rust - I've heard a lot of great things about it. Unfortunately I'm not familiar with the language though, so I'd appreciate some help with this error I get. While corepipe works great for me when run within an Ubuntu 20 WSL2 instance on my Windows laptop, it does not run without error on my device that runs both Ubuntu 20 and Ubuntu 22. I get the following error on both OS versions. It's not obvious to me what's causing this error while browsing the rust code. Do you know what could cause this?

$ sudo ./corepipe --pid 2007
2023-11-23T17:57:35.108Z INFO [corepipe] dumping core for pid 2007 ...
2023-11-23T17:57:35.108Z INFO [corepipe] halted.
2023-11-23T17:57:35.108Z INFO [corepipe] collecting process data...
Error: should be able to read register state

Caused by:
ENODEV: No such device

[jaredhagel]

I just discovered gdb support Rust, so I've narrowed down the problem to the following code in ptrace.rs. When this code works (on my laptop), ptrace_res is 0. When it doesn't work (on my device) ptrace_res is -1. Still debugging...

[jaredhagel]

I investigated a little more. I likely get this error because our device does not support the xsave instruction. /proc/cpuinfo on my laptop contains xsave while this same file on my device does not. Therefore this information (NT_X86_XSTATE or "x86 XSAVE extended state") is not available to be read on my device :( Looks like a great project but if I understand correctly it will not work on our device which is older.

[jasonk000]

Are you saying, your device is not x86? It should be possible to add a new architecture by following notes here: https:/Netflix-Skunkworks/corepipe#adding-an-architecture

If I'm not mistaken I noticed in the comments a mention of MIPS, you might look at the below registers. For context, these register details are extracted so that they are able to provide enough context to the debugger (gdb) that it can correctly build stack traces and register values / parameters that are on the stack. Without these notes the heap will still be valid (I think), but you won't have any ability to do stack traces.

https://elixir.bootlin.com/linux/v6.7-rc3/source/include/uapi/linux/elf.h#L445

#define NT_MIPS_DSP	0x800		/* MIPS DSP ASE registers */
#define NT_MIPS_FP_MODE	0x801		/* MIPS floating-point mode */
#define NT_MIPS_MSA	0x802		/* MIPS SIMD registers */

This should allow you to read those registers and then they need to emitted into a note with the correct label , currently at : https:/Netflix-Skunkworks/corepipe/blob/main/src/write_elf.rs#L25

--

There's no central place currently to support alternative archs, but you can search for instances of #[cfg(target_arch = "x86_64")]. I'm surprised you were able to hit this code for a non-x86_64 platform to be honest as most if it is not wired.

I have access to ARM but not Linux ARM. If it would be helpful I can try to produce an ARM build & test case that might work which should make sure abstractions are in the right place.. ?

[jasonk000]

I've added a quick and dirty implementation that allows for the architecture code to be split to separate file. It should show what's needed - you need (1) a notes spec to define what area will be required at the output stage and (2) the actual output entries. You can find an example for elfmachine_x86_64.rs.

I don't have MIPS to take it much further but I think you can probably copy&paste most of it to get it working.

[jaredhagel]

Sorry it was a busy week. Our device is an x86 device, but it's an older device that does not support the xsave instruction. It seems that this instruction is necessary for corepipe to work. A similar problem with a similar error message is linked here - rr-debugger/rr#1282. As shown in my first post, I was also getting a ENODEV error when calling ptrace(GETREGSET). I verified by examining /proc/cpuinfo that my CPU does not support xsave as well.

[jasonk000]

Hi @jaredhagel , this should be fixed in #5. Let me know how it goes, otherwise I might need a bit more detail on your machine so I can try and replicate it.

[jaredhagel]

Thanks for fixing this @jasonk000! corepipe is not crashing on our device any longer, but I am getting an error from gdb when trying to load the core file on both our older device and my laptop running WSL2:
...core.test" is not a core dump: file format not recognized
Full output from my laptop attached here.
output.txt
I can't remember if I tested that I could load the core dump into gdb without this error before the #5 change you made.

[jasonk000]

Nothing obvious shows in the output. Can you share the readelf output?

On Ubuntu 22.x this is in binutils package, readelf -a <corefile> will dump all header / section information from the elf file and we can check if something is missing.

It would also be useful if you can grab a working gcore with a valid output (you could compile the test apps and use those directly as they should only be a few KB/MB) and we can compare the results.