Compiling strace as a library

[pkmoore]

Hey everyone. As part of another project I needed to enhance the rr debugger to output system call information in strace's format as the application under debug was executing. I hacked together something that got the job done by compiling strace into a static library and directly calling the entry and exit decode/trace/finish functions after setting the required state. I had to to supply a my own umoven() and umovestr() as well. Is this a feature for which there might be an audience if it could be put together in a clean enough fashion? I likely won't have the time to do the required reorganization to make things publishable but I would be glad to help out if someone thinks this is interesting enough to take on.

Either way, the project has my appreciation for maintaining a codebase that is easy to understand and work with.

[esyr]

Thank you for you interest in strace. Note that discussions usually happen on the mailing list, so it probably makes sense to also write there, for the wider outreach.

Overall, the idea has been being in the air for quite a long time, but there are several significant hurdles on the path to its realisation:

• The need of API and the associated maintenance costs. Currently, various parts of strace that deemed to be API-worth are changed from time to time, and it's usually harmless process, but with a library it would be much more cumbersome process. Thinking the API through and implementing appropriate changes to make it at least somewhat future-proof is the main issue (but we can probably go with separating library part first and then stabilise API at some point bu declaring soname 1.0.0).
• The format of the data. As of now, it's just strings. Of course, application that use strace want something more structured, and there were some efforts to implement structured output in strace, but it's not here yet. And again, there's question of output format stabilisation, more so in the string form, as it's changed from time to time.
• Global state. There are lots of global variables used in strace currently, and some functions lack any kind of handle (like struct tcb) to eliminate them. This is mostly technical issue, however.

So, without those bits implemented first I think it's unlikely that strace library is possible/useful, and so far there's no one in sight to implement those in a timely fashion, but otherwise strace project is slowly moving in that direction.

[pkmoore]

Thanks for the info. All that makes perfect sense. I took a little time and created a repo for my modifications and some documentation on how I made things work in my specific case. Here's a link in case anyone with sufficient bravery comes across this issue looking for something similar: https://github.com/pkmoore/strace_output_lib

I'll put this out on the mailing list as well.

Thanks again!

[i-ky]

I am currently working on a pet project involving ptrace and I would be very happy if there was some kind of library aiding in interpretation of ptrace_syscall_info. strace does that brilliantly (e.g. mapping syscall numbers to names for different architectures, extracting argument values), so it would be great if strace project shared some of its expertise with the world.

I am willing to help, but I need to be pointed in the right direction.

[hkerma]

I am also working on a project that would benefit from strace's ability to decode argument system calls flawlessly independently of the architecture. We, for now, use ptrace and poke manually in some registers to decode arguments. Would be willing to help as well.

[ldv-alt]

I am also working on a project that would benefit from strace's ability to decode argument system calls flawlessly independently of the architecture. We, for now, use ptrace and poke manually in some registers to decode arguments. Would be willing to help as well.

Since we introduced the PTRACE_GET_SYSCALL_INFO API in the kernel, there is usually no need to deal with registers to decode syscalls.

[ldv-alt]

I am currently working on a pet project involving ptrace and I would be very happy if there was some kind of library aiding in interpretation of ptrace_syscall_info. strace does that brilliantly (e.g. mapping syscall numbers to names for different architectures, extracting argument values), so it would be great if strace project shared some of its expertise with the world.

I am willing to help, but I need to be pointed in the right direction.

With regards to this idea of creating a library out of strace, little has changed, we are essentially in the same situation as we were back in 2018: #70 (comment)

[hkerma]

I am also working on a project that would benefit from strace's ability to decode argument system calls flawlessly independently of the architecture. We, for now, use ptrace and poke manually in some registers to decode arguments. Would be willing to help as well.

Since we introduced the PTRACE_GET_SYSCALL_INFO API in the kernel, there is usually no need to deal with registers to decode syscalls.

Sure, but how about the system call arguments? We not only need pointers, but they actually decoded arguments, and I believe strace can do help there.

[pkmoore]

It’s been a very long time since I’ve thought about all this. Check out the repo I linked in my 2nd comment from 2018. The README discusses the steps I took to get my very hacky solution working.

This was done in the depths of an (ultimately successful) PhD, and I didn’t have time to clean things up any more than I did. I frankly don’t remember even writing that documentation!

If anyone chooses to go down this road I’m happy to help. In any case, thanks for the trip down memory lane 😁

[hkerma]

@pkmoore I had a look at your repo: it seems strace changed a lot since 2018 but I am trying to start from your code to make it happen again! The repo is here. I forked strace directly and added the othermake file to compile the objects a library. That work is also part of a PhD therefore I don't know if I will have much time to clean/document (or even simply make it work) but I'll try my best! Any help is welcome :)