> The problem with UML is that the tracing thread is started in a
> clone() call, and is difficult to debug: do you have a special gdb
> with clone() support ? Or do you simply attach the process later ?
I attach the process later. gdb on Linux doesn't have any particular thread support, which makes things harder than they need to be.
> I tried to run the input thread in a clone() [instead of signals()]
> and to "mov <signals() info>,%ecx ; mov <new tracing thread stack>
> ,%eax; mov %eax,%esp ; push %ecx ; call <signals>". But for some
> reason the process crashes much _before_ reaching this modification
> (because argv/argc become invalid, because of the remaps???)
You break it, you get to keep both pieces :-)
> What stays also unclear is whether the linux kernel is actually run
> as the "tracing thread", and how memory manipulations are performed,
> when a process calls "brk()" for instance. I guess gdb the tracing
> thread is necessary for figuring out.
I have a nice list of little nitty-gritty things I'm going to write up, and it didn't occur to me to write up something about how the whole thing is organized...
The tracing thread oversees the whole operation, but actual system calls happen in the process that invokes them. That should have been clear in my system call write-up. It wasn't, so could you tell me why it wasn't? I'll see if I can make it more clear.