Gdb needs to be able to read/write process memory between the time the
child is forked and exec is called (in the vfork case). Without the change
it causes a kernel panic when gdb tries to read/write process memory. Since
my understanding of the kernel is a bit limited, it was the best I could do
at the time. I will send more details about the panic once I get a working
fbsd system again. Maybe there's a better way to deal with the panic.
Please provide more details, I am looking forward for the panic
message and backtrace.
As soon as I get my FreeBSD box fixed, hopefully tomorrow.
Lets postpone discussion of the orphan.patch for later.
OK.
The follow-fork.patch and follow-exec.patch make me wonder, and I
already expressed my doubts. IMO, all features, except one bug, are
already presented in the stock src.
More, suggested follow-{fork,exec} patches break the SCE/SCX tracers
notification of fork and exec events, since TDB_FORK and TBD_EXEC flags
are consumed before syscall returns (I also said this previously).
Namely, if the process is being debugged, the successfull [f]execve()
causes unconditional stop even. This makes PT_FOLLOW_EXEC unneccessary.
Existing PT_FOLLOW_FORK implementation indeed has a bug, which was not
revealed by my testing during the development, because I only tested
SCE/SCX scenario. Namely, if PT_FOLLOW_FORK is requested, but the next
stop is not SCX, then follow-fork notification is not sent. After this
nit is fixed, PT_FOLLOW_FORK caller gets stops for the child creation.
Child is put into stop state as needed to not loose it.
I think this will fix only a part of the problem, the one that relates to
PT_CONTINUE.
I still need the change that forces a stop in both child and parent on
fork(). Without my changes the notification is generated in the child but
not in the parent. I need to be able to have both processes stopped in gdb
in order to clean up and detach from the parent, and initialize and attach
to the child. The main reason I need both processes stopped is that gdb has
to be able to read/write into both processes address space and registers.
Ideally I would like to have a single event generated for fork() at a point
where both child and parent are stopped and available for ptrace read/write
requests. Do you think it's possible?
The lack of the notification for parent is exactly what the patch I
posted fixes. More exactly, it is the lack of notification for parent
with PT_CONTINUE loop. I will commit this today.
Regarding a single notification. Currently, parent arrives at the
syscall return code only after the child is attached to the debugger.
See the cv_wait() in kern_fork.c:739. In other words, if you get the
PL_FLAG_FORK, the child is already attached (at last it shall be). My
scescx.c code illustrates this well, IMO.
OK, I see. I need to verify that it works with gdb and possibly tweak it to
match the kernel.
You still get a separate stop from the child, but I do not see how is it
harmful.
It's not harmful as long as gdb can tell that those stops are generated by the
fork().
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
