How to determine what if any system calls are being made by the following C functions
1) execave
2) fork()

I understand that for the fork function call Clone is called but how can I check this and confirm myself?

Thanks

I understand that fork and clone are two different system calls. Read their respective man pages for confirmation.

To see the system calls made by a specific process, use strace.
To see system calls made globally, use the audit subsystem. For an off-the-cuff audit, see the auditctl command.

1 members found this post helpful.

Thank you berndbausch. Is it possible to run gdb set a break point on fork() and then step into fork() to see the code behind fork() in order to see if clone() is called ? I hope this makes sense and is clear.

This is the second (very) similar thread. I'm still not sure what you are asking - or if you know yourself what you are asking.

If you really have to know, go look at the source. Else the kernel now has quite extensive tracing that allows you to dynamically step into kernel-space functions as they are running. Perhaps have a look at sysdig - it does all the setup work for you and has tools that will do what you want. Has a learning curve, but far less than learning the underlying tracing infrastructure itself.

1 members found this post helpful.

Perhaps, but if you see fork in strace or audit, you know that it is a system call.

Actually, it is sufficient to consult the system call list.

1 members found this post helpful.

Thank you for the post. This is what I am trying to do is to find out whether fork() calls the clone() system call.

You're asking a question where you've already received the pathway to the answer.

The truth is that fork() defines system calls, and I feel you'd see this by inspecting the code.

I applaud you for asking deep questions about the kernel implementation, however I do not feel that you can only go by Q&A here, you really do need to study the code for the various kernel components you are asking about.

At that point, it becomes the question of, "are you interested in becoming a deep core kernel developer, or not?", and that's a question you may have a quick response to, "YES!" with excitement, or you may not know. But once you start reading some code, you may find, as I very much have found myself, that a lot of the code in there is not stuff I wish to play around with much.

It's not as simple as running GDB, you can run GDB on code you have, but it won't do you much good going into normal C libraries, because those are binaries, and the same applies to the kernel, you should have the matching kernel source on your system, but what is running has been optimized and has had the symbols removed. So like any debugger when you go into a library or system call, you find yourself at the assembly level, no symbols, and you can single step, but you have no idea what or where it is, especially well enough to discern much.

I've actually done one form of kernel development. Built in variables, and printk's. I asked at the time, "Hey! We probably use KDB here, ... right?" I mean, I was in a kernel development shop. And everybody looked at me askance, meaning, "Knock yourself out cowboy."

And so I gave it a try, but could not get it to work for me, so I mimicked my peers. I'll admit, that I've "configured and compiled" many custom kernels and done some minor code modifications, mostly to drivers, but I'm no kernel developer.

That said, when I've had deep core issues where I needed to modify something in the kernel, I've found what I needed by looking at the code and writing modifications, just not written entire system calls from scratch.

Same point is if I had a burning question about some kernel code, I'd read that code.